Consultor Eletrônico

Button & menu accelerators do NOT fire ENTRY, LEAVE triggers


ACCELERATOR BEHAVIOR WITH BUTTONS AND MENU-ITEMS
------------------------------------------------

Developers often ask whether invoking a button or menu accelerator
should fire LEAVE and ENTRY triggers, and whether FOCUS should then
move to the button or menu item. The answer to both of these
questions is NO. (This applies both to buttons with acclerators
defined and for buttons which themselves are defined as "default"
buttons.)

To illustrate the problem, we'll use an example of three fill-in's
and a button. The button label will be "&Push", signifying that
ALT-P would be the keyboard accelerator for the button CHOOSE.

If a user is on fill-in-2 and invokes ALT-P, the button CHOOSE
trigger will fire, but focus will remain on fill-in-2 and no LEAVE
or ENTRY triggers will fire. This is expected behavior, and
furthermore is a MS-Windows and Motif standard.

The alternative, to have entry go to the widget whose accelerator is
invoked, is best illustrated using the PROGRESS Procedure Editor.
If while working in the Procedure Editor you decide to do a "Replace"
operation by pressing CNTL-R, you wouldn't want to end up with focus
in the drop-down menu for "Edit -> Replace" and have to use the
mouse to get the cursor back into the file you're editing.

If the default behavior of accelerators seems to disrupt the
way you've conceived your application, perhaps you should examine
whether an accelerator is truly appropriate for the widget being
invoked. In the Procedure Editor example, the "Replace" operation
is ideally suited for acceleration, since it does a specific task
within the editor and does not impact calculations, database
operations, etc.

You should also take a careful look at the way you might be
implementing LEAVE and ENTRY triggers. For example, if you
are doing field validation based on LEAVE, you might want to
rethink this strategy since it is not entirely GUI-friendly. (In a
true GUI environment, Progress recommends using schema triggers and/or
the trigger block for an "Ok" button for carrying out validation.
Use of ON LEAVE is more of a Version 6 concept and might confuse
users who are accustomed to the free-form UI they encounter in other
MS-Windows and Motif applications. GUI users don't like to be
trapped in any one field until they've satisfied the whim of the
application! GUI design is about options and flexibility.)


ACCELERATOR BEHAVIOR WITH OTHER FIELD-LEVEL WIDGETS
---------------------------------------------------

Accelerators for fill-ins, toggle boxes, and radio sets behave
differently from those for buttons and menu-items. For these
widgets, ENTRY and LEAVE triggers do fire, and focus does move
to the widget whose accelerator has been invoked by the user.

The reason for this lies in the MS-Windows standard for accelerators.
Widgets such as fill-ins, toggle boxes, and radio sets are used
for data entry, while buttons and menu-items are used to change the
state of an application. For data-entry type widgets, it makes more
sense that a user invoking the accelerator would want to go to that
widget and effect some change to its screen value, for instance by
typing in some text to the fill-in. To *not* apply entry under
these circumstances would be counter-intuitive. For widgets that
change the state of an application, such as buttons and menu-items,
applying entry is not necessary in making use of their functions;
in fact (as discussed earlier) it can be disruptive.

While programmers may disagree with the way these rules are laid out,
it is MS-Windows which enforces the default behavior. Any desire
to circumvent the behavior will have to be done programmatically,
in the 4GL. Such code changes would be complex and developers may
also wish to consider whether they truly wish for their particular
applications to work counter to MS-Windows standards, possibly
resulting in confusion and frustration for their users.

Progress Software Technical Support Note # 13863