| **Navigation:**  [[introduction.htm|Language Reference]] > 9 -  Window and Report Attributes > Window and Report Attributes >====== ALRT (set window "hot" keys) ====== | [[alone set to print without page header footer or form .htm|{{btn_prev_n.gif|Previous page}}]][[introduction.htm|{{btn_home_n.gif|Return to chapter overview}}]][[angle set control display or print angle .htm|{{btn_next_n.gif|Next page}}]] | | || {{newc7.jpg|NewC7.jpg}} **ALRT(**//keycode//**)** {{blk2blue.jpg|blk2blue.jpg}} | **ALRT** | Specifies a "hot" key active while the APPLICATION, WINDOW, or control on which it is placed has focus. | | //keycode// | A numeric constant keycode or keycode EQUATE. | The **ALRT** attribute (PROP:ALRT) specifies a "hot" key active while the APPLICATION, WINDOW, or control on which it is placed has focus. When the user presses an ALRT "hot" key, two events (field-independent if the ALRT is on an APPLICATION or WINDOW, field-specific if the ALRT is on a control), EVENT:PreAlertKey and EVENT:AlertKey, are generated (in that order). If the code does not execute a CYCLE statement when processing EVENT:PreAlertKey, you "shortstop" the library's default action on the alerted keypress. If the code does execute a CYCLE statement when processing EVENT:PreAlertKey, the library performs its default action for the alerted keypress. In either case, EVENT:AlertKey is generated following EVENT:PreAlertKey. When EVENT:AlertKey is generated, the USE variable of the control with input focus is not automatically updated (use UPDATE if this is required). You may have multiple ALRT attributes on one APPLICATION, WINDOW, or control (up to 255). The ALERT statement and the ALRT attribute of a window or control are completely separate. This means that clearing ALERT keys has no effect on any keys alerted by ALRT attributes. PROP:ALRT is an array, containing up to 255 keycodes. The array element number actually used is internally assigned to the first free array element if the specified element number is larger than the current number of assigned keycodes. For example, assuming there are no keys alerted at all, if you specify assigning to element number 255, it is actually assigned to element number 1. Subsequently assigning another keycode to element number 255 (still free), it is actually assigned to element number 2. Explicitly assigning a keycode to element number 1, however, overwrites any other keycode already assigned to element number 1. In fact this happens to //any// element that has a keycode and if an additional alert assignment is made to an element that is already assigned. **Example:** **WinOne WINDOW,AT(0,0,160,400)** **        ENTRY,AT(6,40),USE(SomeVar1),****ALRT****(MouseLeft) !Mouse click alerted for control** **        ENTRY,AT(60,40),USE(SomeVar2),****ALRT****(F10Key)   !F10 alerted for control** **       END** ** CODE** ** OPEN(WinOne)** ** ACCEPT** **  CASE FIELD()** **  OF ?SomeVar1** **   CASE EVENT()** **   OF EVENT:PreAlertKey  !Pre-check alert events** **    CYCLE                !Allow standard MouseLeft action to process** **   OF EVENT:AlertKey     !Alert processing** **    DO ClickRoutine** **   END** **  OF ?SomeVar2** **   CASE EVENT()** **   OF EVENT:AlertKey     !Alert processing** **    DO F10Routine** **   END** **  END** ** END** **!***********example showing how to clear an alerted key** **LOOP I# = 1 TO 255** **  IF Window{Prop:ALRT,I#} = AltA   !clear the AltA keycode** **    Window{Prop:ALRT,I#} = 0** **    BREAK** **  END** **END** **See Also:****     [[alert set event generation key .htm|ALERT]]**