In the programs I developed with Version 2.3 and 2.4, I used the configuration variable MOUSE-FLAGS to detect certain mouse events. After updating my screens to include graphical controls, I notice that the double-clicked events that I used to get in my entry fields are no longer generated. What's going on?
MOUSE-FLAGS does not detect any event that takes place over a control. Mouse events that take place over a control are handled differently than mouse events that interact with text-based screen items. The mouse, when positioned over a control, is owned by the control. All mouse events that take place over the control are sent directly to and handled by the control. List-box controls are the only controls that pass double-click events back to the program. To detect a double-click in a list box, check for CMD-DBLCLICK in EVENT-STATUS.
In my configuration file I have a KEYSTROKE entry that defines carriage return (^M) to have both a termination and exception value of 13. It also defines edit=next so that a carriage return also moves the cursor to the next field. But when I have a screen that includes an OK button and a carriage return is pressed, the screen terminates and the cursor is not moved to the next field.
This is the correct behavior. Remember that the OK button style also implies the DEFAULT button style. The DEFAULT button style has the effect of acting as if it is pushed whenever a key with the value of 13 is pressed.
A program running in UNIX with the configuration variable KEYSTROKE EDIT=Next terminate=17 kr and KEYSTROKE EDIT=Previous terminate=17 kl can return to the previous field or advance to the next field when the <left arrow> or <right arrow> keys are pressed, but when the program is running in Windows these keys do not work.
This is the correct behavior. When using controls, the host GUI determines the meaning of any editing keys in the control itself. For our own simulated GUI, we allow you to define the editing functions using the KEYSTROKE entries. For other systems (such as Windows), the host determines how keys are used. In the case of Windows, the left and right arrow keys move the cursor but do not act as terminators.
While the run-time does allow you to configure which keys are terminating keys (even for Windows), it cannot force the host GUI into a mixed mode where a key is sometimes an editing key and sometimes a terminating key.
With the KEYSTROKE configuration variable I redefine the menu activation key. The redefinition works fine under UNIX but doesn't under Windows. Why?
Windows' menu activation keys are not configurable. The only keys available are the ones defined by Microsoft. The menu activation key under Windows is F10.
In many of my character-based applications I use BLINK to highlight some text. Why is it that when I run those applications under Windows, the text doesn't blink?
BLINK isn't supported under Windows.