Progress
Portability Guide
Mouse Events
Progress supports two types of mouse events: physical events and portable events. You can use portable events to associate triggers with logical actions of any mouse. You can use the physical events to associate triggers with specific physical actions of a mouse.
Progress uses a logical (portable) model to reference mouse button input. This ensures that your application works in any supported operating environment, such as Windows and UNIX. Progress also provides access to the physical mouse input of your operating environment, if necessary. Both forms of input are available as events in a manner similar to keyboard events.
Portable and Physical Buttons
Progress supports four portable mouse buttons:
Although Progress supports two-, three-, and four-button mice, the standard mouse used with Windows has only two buttons. Therefore, some physical mouse buttons must have double functions or you must use control keys with one or more buttons.
Table 3–12 shows the mappings between the Progress portable mouse buttons and the physical mouse buttons on Windows.
Physical mouse events take priority over any corresponding portable event. If you define a MOUSE-SELECT-CLICK and a LEFT-MOUSE-CLICK trigger for the same widget, Progress only fires the LEFT-MOUSE-CLICK trigger. Therefore, when choosing the events to associate with a trigger, use portable mouse events whenever possible.
Progress automatically maps a portable mouse event to the mouse key used by the native window system to perform the same event. In other words, Progress supports a window system that uses either the left or the right button as the select button. The portable MOUSE-SELECT-CLICK event automatically maps to the right button for that system.
NOTE: If porting to a system that does not support a mouse, you can replace mouse events with functional events, such as SELECTION, ENTRY, and MENU-DROP.Low-level and High-level Events
Both portable and physical mouse events fall into two classes: low-level and high-level mouse events. You generate low-level mouse events with the simplest mouse button action in a single direction, such as up or down; and you generate high-level events with more complex actions, such as click or double-click.
Low-level mouse events take priority over corresponding high-level mouse events. For example, if you define a MOUSE-SELECT-UP and MOUSE-SELECT-CLICK trigger on the same widget, only the MOUSE-SELECT-UP trigger executes. Therefore, use high-level mouse events exclusively whenever possible. If you must use low-level events, do not mix low-level and high-level event triggers on the same widget. Processing both classes of events on the same widget can lead to unintended results.
While Progress always recognizes corresponding low-level and high-level events, it executes only one trigger for both. Progress looks first for a trigger on a low-level event. If there is no trigger on a low-level event, Progress looks for a trigger on a high-level event. Once it finds and fires a trigger, it waits for the next event. However, each graphical interface might recognize and pass high-level events to Progress after recognizing a different combination of low-level events. For example, one system might recognize a double-click on a down-mouse event and another system might recognize the double-click on an up-mouse event. This causes mixed event sequences to differ significantly among interfaces.
Mixing low-level and high-level mouse events creates portability problems among graphical interfaces. Furthermore, the expected event sequences in the same graphical interface might change in future versions of that interface.
Table 3–13 lists the mouse events that apply to all mouse devices, regardless of how the buttons are configured, and indicates the level of each event.
Table 3–14 lists the mouse events associated with physical mouse buttons and indicates the level of each event.
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |