Q. 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 use to get in my entry fields are no longer generated. What's going on?
A. 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.
Q. 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.
A. 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.
Q. With the KEYSTROKE configuration variable I redefine the menu activation key. The redefinition works fine under DOS but doesn't under Windows. Why?
A. 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.
Q. In many of my DOS applications I use BLINK to highlight some text. Why is it that when I run those applications under Windows, the text doesn't blink?
A. BLINK isn't supported under Windows.