Consultor Eletrônico

Why you can't APPLY hardware events (scrolling, mouseclick)

This knowledgebase 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 menubar,
the click of one of the mousebuttons (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, there
is no way to make these events physically occur on the GUI
interface so that the user visually perceives them.

(Although the examples in this knowledgebase refer only to the
MS-Windows environment, the issues involved apply equally to
OSF/Motif and character-mode PROGRESS.

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 affordance 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 use clicks on a button widget, a DLL
in MS-Windows has built-in animation which gives the
button an appearance of being pressed in 3-D. 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 3-D 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 affordances which detect 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 affordance which allows us actively to 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 viewport 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 menubar 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. No can do.

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.)

Will this situation ever change? At present, no. There
are no plans currently in place to implement active event
handling in PROGRESS.

Progress Software Technical Support Note # 13833