Consultor Eletrônico

Status: Unverified

GOAL:

Why you cannot APPLY hardware events (scrolling, mouse click)

GOAL:

Why certain hardware events cannot be supported in PROGRESS?

FACT(s) (Environment):

All Supported Operating Systems
Progress/OpenEdge Versions

FIX:

This solution explains why certain hardware events cannot be supported in PROGRESS. In speaking of "hardware events" what we mean are actions such as the scrolling of a frame or editor widget, the drop-down of a submenu from a menu bar, the click of one of the mouse buttons (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 is possible to use the APPLY statement to make trigger code execute, it is not possible to make these events physically occur on the GUI 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 PROGRESS cannot support these behaviors is due to the way we support events in general. The event model incorporated into PROGRESS is a "passive" one, meaning that while we can receive events from the native windowing system, we cannot and do not actively send events back to it. The role of PROGRESS in this model is strictly reactive.

For 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 MS-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 ON CHOOSE trigger block is that it can be invoked within the 4GL without action by the user, by means of an APPLY statement. In a sense, doing an APPLY CHOOSE within PROGRESS "simulates" the receipt of a physical CHOOSE from MS-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 acts on 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 MS-Windows. MS-Window's 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 us, and it is this information which of course is most important.

In order for PROGRESS 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 we can passively accept events from MS-Windows, we do not have any functionality which allows us actively to send them back.

This lack of "active" event handling is the reason that scrollable widgets c.annot 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..