Automatic "S" attribute in RINPUT FIELDS

[Susan Smith]

As I mentioned in another message, I am discovering some features in 4.18 (as I begin to use it more) that have changed from 4.17. I have not seen any mention of these in the release notes, but perhaps I just overlooked that section. I'm not happy about these, so I'm looking for workarounds.

The inability to color a protected field differently than OTHER protected fields was the first one I mentioned. There are legitimate reasons to desire this flexibility. I have done this for years, if not decades. But no more in 4.18.

The other thing that APPARENTLY has changed involves the "S" (for sunken fields) attribute. It seems that this is no longer an OPTION for RINPUT fields. If you remove the "S" attribute from RINPUT FIELDS specs, you get the sunken look ANYWAY in 4.1. It was not the case in 4.03, I'm converting a legacy system now, which is why I'm noticing it. This royally messes up a particular screen I have where which now looks positively amateurish with the sunken look everywhere. But I have no choice other than to go BACKWARDS and use separate INPUT FIELDS statements and handle all of the navigation myself. Why the change and removal of flexibility?

For most situations, the sunken look may be desired, but not all situations. I'd prefer to use the "S" attribute when I need it and drop it when I don't. Is there a workaround that I'm just not aware of? I'd LOVE to be wrong

-- Susan

[Gabriel]

As I mentioned in another message, I am discovering some features in 4.18 (as I begin to use it more) that have changed from 4.17. I have not seen any mention of these in the release notes, but perhaps I just overlooked that section. I'm not happy about these, so I'm looking for workarounds.

The inability to color a protected field differently than OTHER protected fields was the first one I mentioned. There are legitimate reasons to desire this flexibility. I have done this for years, if not decades. But no more in 4.18.

The other thing that APPARENTLY has changed involves the "S" (for sunken fields) attribute. It seems that this is no longer an OPTION for RINPUT fields. If you remove the "S" attribute from RINPUT FIELDS specs, you get the sunken look ANYWAY in 4.1. It was not the case in 4.03, I'm converting a legacy system now, which is why I'm noticing it. This royally messes up a particular screen I have where which now looks positively amateurish with the sunken look everywhere. But I have no choice other than to go BACKWARDS and use separate INPUT FIELDS statements and handle all of the navigation myself. Why the change and removal of flexibility?

For most situations, the sunken look may be desired, but not all situations. I'd prefer to use the "S" attribute when I need it and drop it when I don't. Is there a workaround that I'm just not aware of? I'd LOVE to be wrong

-- Susan

So, what you're trying to do is have the user be able to input from something that is not a text box? I mean, you want the user to be able to type in a blank section of the screen?

How is the user supposed to know they can type there if its not a sunken field?

I think as we move forward we should do our best to embrace windows and modern computer interface standards whenever possible. Can you give more details in your example? Why do you want the user to not have a visual indicator that they're allowed to type there?

Gabriel

[Susan Smith]

Well, there can be several reasons not to want text boxes around individual input fields. One is a mini-calculator application where you are trying to enter numbers on the "adding machine "tape".

Another has to do with the limitations of rows and columns. When you use sunken text boxes, your text is necessarily going to be smaller because of the need to save space for the text box border. But there are times when you may want your text to be larger and stand out more. I can color the backgrounds of such fields differently so that they APPEAR to be text boxes without borders, but the text can still take up the full amount of height.

Incidentally, this same issue applies to protected fields which still display the text box border around them even when they are protected, which brings us back to the inability to INDIVIDUALLY make a particular PROTECTED field display differently from other protected fields. I posted your idea of displaying protected fields as captions or labels instead of as protected data fields. That works, but if the field's protection gets turn on and off during program execution, you don't have the luxury of doing that either.

If I lived in a perfect BR world, I would be able to specify the "S" attribute WHEN I wanted it (which might be most of the time) just we used to be able to do. And I'd be able to individually customize the display of protected fields with any color, font or even the "S" attribute to draw a box around it. I could have a default (like [INACTIVE]) specified in BRCONFIG.SYS, but it would be overridable just like any other input field.

Developers are constantly creating new types of applications that, for some reason or another, can't always fit the Windows model. Why "box" ourselves in and limit ourselves in case we want to write something slightly out of the box in BR?

-- Susan

[gordon]

These issues may relate to Windows Themes. The 4.18 release notes state:


Themes alter the way Windows displays fields (control elements). Microsoft first began using themes with XP. The 'classic look' is the Windows 2000 appearance, which is what is produced when themes are suppressed. Vista permits users to select from among several themes as a part of the user's desktop settings. Sometimes theme processing can slow down the display of large quantities of data, and sometimes it can create an appearance that is less desirable than the classic look.

A new field attribute is defined that may be specified in ATTRIBUTE statements
and in FIELDS leading attributes:

^NOTHEME indicates prevent use of Windows Themes

Also a new config statement is available:
CONFIG WINDOWS_THEMES OFF | ON
This entirely suppresses the use of Windows themes.

You might try turning Themes off to see if that makes a difference.

[Susan Smith]

Thanks Gordon. I'll give that a try!

-- Susan

[GomezL]

The basic problem you are encountering is that in GUI ON mode, input fields uses objects rather than just "Painting" a picture of an input box.

I do not think that windows offers a control that allows data input, but also has no lines.

The other problem is the concept of "Inactive". An inactive field in windows has a certain behavior. Protected fields are inactive as well as "Old Input Fields" that are no longer active.

Labels in windows behave much more the way you want. In BR, PRINT FIELDS will create a Label. These labels may have any attribute you wish, and may be sunken or not.

[Susan Smith]

I appreciate this explanation. Thank you. Now I know that I just have to live with it.

With the project I am working on, I am not able to create any controls on the fly (either input fields or buttons). They have to be set up in advance in the screen painter and their behavior is not really changeable at runtime EXCEPT by adding a "P" protect attribute. Pre-GUI, I could turn an "input field" into a "print field" at runtime by adding the "P" attribute and leaving the color attributes alone. I see that this is not the case in GUI: I can PROTECT it at runtime, but it will necessarily LOOK like every other protected field.

And on a related note, it appears that these same rules apply to buttons. I can't make a button (already created) conditionally disappear at run time if I don't want SOME users to see it. I can protect the button, but then it looks like any other protected field.

I think I'm beginning to "get this" now. Thanks again Louis. There are times when somebody just has to tell me "No, you can't have that". Knowing WHY helps though.

-- Susan