Kbase 16949: Triggers for keyboard events disable default behavior
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
Triggers for keyboard events disable default behavior
If you write trigger code for keyboard events within a widget,
such as ON CURSOR-UP or ON CURSOR-DOWN, you will find that the default
behaviors typically associated with these keys no longer happen when
the triggers fire.
This is a known property of PROGRESS's event management. If a
hardware event is "trapped" by trigger code in an application, once
the client grabs the event it is no longer passed along to the host
environment. In this case, it means that the cursor key events are
no longer sent to the editor widget itself. The trigger fires, but
the cursor no longer moves up or down.
This is not a bug.
Programmers are referred to the discussion of "Events" in the
PROGRESS documentation. (In Version 8, this chapter is contained
in the "PROGRESS Language Reference: Widgets, Attributes, & Methods,
Events and Indexes." The section on Triggers and Low-level Keyboard
Events states:
"Some low-level keyboard events cannot have associated
triggers and maintain their default behavior at the same
time. In general, if PROGRESS gets an event from the user
interface system that has a trigger associated with it,
PROGRESS handles the default behavior and tells the user
interface system to ignore the event. This allows PROGRESS
to cancel the default behavior in response to a RETURN
NO-APPLY invoked by the trigger.
"However, there are some low-level keyboard events for which
PROGRESS does not handle the default behavior. These include
the cursor keys, especially. When PROGRESS gets one of
these events with an associated trigger, it tells the UIS
to ignore the event as usual, but because PROGRESS does not
handle the default behavior for the event, the standard
UIS behavior is lost we well. Thus, a cursor key event
(for example, CURSOR-UP or CURSOR-DOWN) that has an associated
trigger does not move the cursor.
"... For those low-level, non-printable, keyboard events
that are not handled by PROGRESS, do not associate triggers
with them unless you do not want the default behavior for
the event."
One way to work within the bounds of this behavior is to add 4GL
code as part of the trigger which carries out the default behavior.
For an editor widget and a CURSOR-UP trigger, for example:
ON "CURSOR-UP" OF editor-1 IN FRAME frame-a DO:
MESSAGE "Cursor up" VIEW-AS ALERT-BOX.
editor-1:CURSOR-LINE = editor-1:CURSOR-LINE - 1.
END.
Note that even if the trigger block is completely empty of code, the
default behavior is still lost, since the client still sees that you
are trapping for the event. As long as there exists an "ON CURSOR-UP"
statement, the event will be subject to the bounds described in
the documentation.
Progress Software Technical Support Note # 16949