Progress
Programming
Handbook


Applying Events

You can use the APPLY statement to explicitly send an event to any widget from within a program, including insensitive widgets. If a trigger is currently active for that event-widget pair, the trigger executes. Progress handles the event as if it came from the user (provides default handling) or not, depending on the event-widget pair and whether the trigger returns NO–APPLY.

The following example applies the VALUE–CHANGED event to a browse widget:

p-apply.p
DEFINE QUERY custq FOR customer.
DEFINE BROWSE custb QUERY custq DISPLAY cust-num name WITH 15 DOWN.

FORM
   customer EXCEPT comments
   WITH FRAME y SIDE-LABELS.

ON VALUE-CHANGED OF BROWSE custb
  DO:
     DISPLAY customer EXCEPT comments WITH FRAME y.
  END.

OPEN QUERY custq FOR EACH Customer.
ENABLE custb WITH FRAME x.

APPLY "VALUE-CHANGED" TO BROWSE custb.

ENABLE ALL WITH FRAME y.

WAIT-FOR WINDOW-CLOSE OF CURRENT-WINDOW. 

Without the APPLY statement in p-apply.p, the first customer record would not initially appear in frame y.

NOTE: In an APPLY statement, the event name must be enclosed in quotes (“ ”).

Default Processing of Events

In addition to executing any trigger you have defined for an event, the APPLY statement might also cause the default processing for the event-widget pair by Progress. For example, applying “A” to a fill-in field inserts the letter “A” at the cursor position in the field. However, some event-widget pairs do not get Progress default processing using the APPLY statement. For example, applying the CHOOSE event to a button executes any trigger on that button, but does not give focus to the button.

Triggers Versus Internal Procedures

If you only want your trigger to execute, consider making that trigger code an internal procedure and running the procedure rather than using the APPLY statement. For example, in the following procedure, the CHOOSE trigger for the fore–one button fetches the next customer record (or refetches the current record if there are no more records). This same action is required within several other triggers and within the main code:

p-repos3.p
DEFINE BUTTON back-one  LABEL "<".
DEFINE BUTTON back-fast LABEL "<<".
DEFINE BUTTON fore-one  LABEL ">".
DEFINE BUTTON fore-fast LABEL ">>".

DEFINE QUERY scroll-cust FOR Customer SCROLLING.

FORM
  Customer.Cust-num Customer.Name SKIP
  back-fast back-one fore-one fore-fast
  WITH FRAME cust-frame.
  
  
OPEN QUERY scroll-cust FOR EACH Customer NO-LOCK.

ENABLE back-fast back-one fore-one fore-fast WITH FRAME cust-frame.

ON CHOOSE OF back-fast
  DO:
    /* Position back 10 records (or to beginning) and
       fetch  the next record from there.            */
    REPOSITION scroll-cust BACKWARD 10.
    RUN next-one.
  END.
  
ON CHOOSE OF back-one
  DO:
     /* Position to previous record and fetch it. */
     REPOSITION scroll-cust BACKWARD 2.
     RUN next-one.
  END.

ON CHOOSE OF fore-one
   DO:
      RUN next-one.
   END. 
ON CHOOSE OF fore-fast
   DO:
      /* Position forward 10 records (or to last record) and fetch. */
      REPOSITION scroll-cust FORWARD 9.
      RUN next-one.
     
   END.

/* Fetch the first record. */
RUN next-one.

WAIT-FOR WINDOW-CLOSE OF CURRENT-WINDOW.


PROCEDURE next-one:
      /* Fetch the next record. */
      GET NEXT scroll-cust.
      IF QUERY-OFF-END("scroll-cust") THEN
        GET PREV scroll-cust.
      DISPLAY Customer.Cust-num Customer.Name WITH FRAME cust-frame.
END PROCEDURE. 

However, rather than applying CHOOSE to fore–one to execute the action, the fetch code has been moved to an internal procedure (next–one). That procedure is then run from within triggers and the main code as needed. Running an internal procedure is more efficient than applying an event because you avoid the overhead of event handling.

Event–Widget Independence

With the APPLY statement, you can actually send any event to any widget for which you have defined a trigger for that event. Progress executes the trigger even if there is no default handling for that event associated with the widget. Thus, you can use this feature to extend the repertoire of developer events (U1 to U10) to include any event (non-standard event) not normally associated with a widget.

NOTE: If you use a nonstandard event-widget association, remember that future Progress versions might make that event-widget association standard and thus introduce unexpected default handling.

For more information on the APPLY statement, see the Progress Language Reference .


Copyright © 2004 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095