This article explains why certain hardware events cannot be supported in PROGRESS. The term "hardware events" is loosely defined as actions such as the scrolling of a frame or editor widget, the drop-down of a submenu from a menu bar, mouse button clicks (e.g., MOUSE-SELECT-DOWN), or the appearance of a pop-up menu without the user having to use the mouse or keyboard.
While it is possible for a user to do all of these things with the mouse or keyboard, and in some cases it's possible to use the APPLY statement to make trigger code execute, it is not possible to make these events physically occur in the user interface so that the user visually perceives them.
Many users have wanted to be able to apply the kind of event which might scroll an editor widget from left to right or make a submenu drop down and appear to the user without any mouse activity being necessary. While in the latter case it is possible to APPLY MENU-DROP and have its associated trigger code execute, there is no way in any case to have the widget on the screen visually reflect the effect of these events. This is because PROGRESS does not include any functionality to do this.
The reason these behaviors cannot be supported is due to the way that the ABL supports events in general. The event model incorporated into the ABL is a "passive" one; meaning that while events can be received from the native windowing system, the AVM cannot actively send events back to it. The role of the AVM in this model is strictly reactive.
As an example; when a user clicks on a button widget, a DLL in MS-Windows has built-in animation which gives the button an appearance of being pressed in 3D. At the same time, a CHOOSE event is generated by Windows and sent to PROGRESS. If the PROGRESS program then has a trigger block written for ON CHOOSE of the button, this code executes. The user not only sees the graphical button getting pressed, but sees the result of that action programmatically.
At the same time, another feature of the CHOOSE trigger block is that it can be invoked within the ABL without action by the user, by means of an APPLY statement. In a sense, executing APPLY "CHOOSE" within the AVM "simulates" the receipt of a physical CHOOSE from Windows and the user of the program.
There is one major difference, however; the *look* of the button in question does not change -- there is no simulation of the 3D appearance that happens when someone physically clicks the button with the mouse. In fact, the button's appearance does not change at all, nor does focus move to it unless it is programmatically directed to do so.
This illustrates an important distinction between hardware and non-hardware events. When a user physically clicks on a button with the mouse, that click is a hardware event which at that particular moment is being handled exclusively by Windows.
Microsoft Windows' interface to the user includes functionality which detects the hardware action. Once the action is detected, it routes the necessary information to the DLL supporting the button, which then causes the change in how the button looks. This processing has not yet involved PROGRESS in any way: we're not brought into the picture until MS-Windows has passed along the CHOOSE event to the AVM, and it is this information which of course is most important.
In order for the AVM to cause the same change in button appearance there would have to be a way for us to send information back to MS-Windows and instruct it to tell the DLL to make the change happen. But, this "active" model of event handling is precisely what PROGRESS lacks. While the AVM can passively accept events from MS-Windows it does not have any functionality which allows it to actively send them back.
This lack of "active" event handling is the reason that scrollable widgets cannot be scrolled programmatically. For example, there's no way to cause a browse, editor, or scrollable frame to move its view port because the required change in widget appearance would mean having to go back out to MS-Windows and tell the associated DLL to make the change. Similarly, there's no way to make a submenu physically appear to a user without the user first clicking on the menu bar to invoke it -- being able to do so would require sending an event out to MS-Windows and telling it to make the menu drop down.
The one exception to this is with fill-in widgets. It *is* possible to APPLY "k" TO FILL-IN-1 and see the letter "k" appear. This is due to the way PROGRESS manages screen buffers and is architecturally part of the product. In a sense, the "k" that you're seeing is living in screen-land and isn't part of the actual widget (hence the concept of SCREEN-VALUE.)
There are no current plans in place to implement active event handling in PROGRESS.