Some low-level keyboard events cannot have associated triggers and maintain their default behavior at the same time. In general, if the AVM gets an event from the user interface system (UIS) that has a trigger associated with it, the AVM handles the default behavior and tells the UIS to ignore the event. This allows the AVM 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 the AVM does not handle the default behavior. These include the cursor keys, especially. When the AVM gets one of these events with an associated trigger, it tells the UIS to ignore the event as usual, but because the AVM does not handle the default behavior for the event, the standard UIS behavior is lost, as well. Thus, a cursor key event (for example, CURSOR-UP) that has an associated trigger does not move the cursor.
Note that for many low-level events, such as mouse button and printable character events in fill-in fields and editors, the AVM does provide the default handling. Triggers on these events have no effect on the default event behavior unless they return NO-APPLY. The same is true of keyboard events that generate high-level functions, such as TAB and RETURN.
For those low-level, non-printable, keyboard events that are not handled by the AVM, do not associate triggers with them unless you do not want the default behavior of the event. For those low-level events that have no standard UIS behavior (such as, programmable function keys) triggers have no negative effects, and in fact, are very useful in defining a program action. In general, check any questionable low-level events in a test procedure both before and after associating triggers with them to see if any standard behavior is affected. An empty trigger block is sufficient to detect differences in behavior. For example:
