Key monitoring

Often, an application does not need to be aware of specific keystrokes or mouse actions by the user because the normal functionality provided by ABL and the window system is sufficient. This is frequently true when you use the procedure-driven programming model. However, you might want to define a special behavior to occur when the user presses a specific key or mouse button. For example, every time the user presses a certain key, you might want to display a message or take some action. This is called monitoring the user's keystrokes. ABL provides a set of language constructs to do this, including user interface triggers. For more information, see Monitoring keystrokes during data entry.

During a session, the AVM responds to key code events according to a precedence that depends on the current user interface and the application design. The following table shows the general order of precedence for ABL key code events.

Table 34. ABL key input precedence
Precedence (high to low)	Key code event
8	In the accelerator list for the current window
7	In the event list for an active user interface trigger
6	An active popup menu key
5	An active menu mnemonic key
4	An active field-level (button) mnemonic key (Windows only)
3	A special ABL internal key (built-in key function, like GO)
2	A key associated with a key function in the PROTERMCAP file (UNIX only)
1	A standard input key ("A", "B", and so on)

Thus, when the user presses a key, the AVM first checks to see if it corresponds to an active accelerator in the current window. If not, the AVM checks for a user interface trigger for that key, then whether the key displays a popup menu, and so on. If the key corresponds to no other function, the AVM processes it as data input, with any required character validation.