Triggers for Pre- and Post-Processing

Triggers for preprocessing determine what happens when something new happens. Triggers for postprocessing determine what happens after an event is completed.

For example, the exec operation is activated before a form appears on the screen. An entity's getFocus trigger is activated before the entity occurrence in a form gets focus and is made available to the user for further work.

Triggers for postprocessing are only relevant for the currently active field, key, or occurrence. They are used to code ProcScript that updates the data after the user leaves a field, a modified key, or a modified occurrence. They are not used for component-level events, such as printing or retrieving data for all painted entities.

Pre- and Post-Processing ProcScript Modules
Level Preprocessing Trigger/ Operation Postprocessing Trigger Activation
Application trigger apStart

apStart

Application started: what to do first, and, if required, last.

Component

operation exec   Start of component: what to do first, and, if required, last.
trigger preActivate trigger postActivate
Entity trigger getFocus (Entity) trigger leaveModified

trigger leaveModifiedKey

trigger leavePrinted

For each occurrence when it gets or loses focus.
Field

trigger getFocus (Field)

trigger valueChanged

trigger loseFocus (Field)

For each field when it gets or loses focus.
  trigger startModification trigger valueChanged When the end user tries to modify a field.
Header, trailer, and break frames trigger getFocus (Frame)   For each header, trailer, and break frame when the frame gets focus.

Modifying a Field in a Form

When an end user modifies a field in a form component, the Structure Editor activates a sequence of triggers, starting with the Start Modification trigger. It is activated as soon as the end user tries to edit a field, and before the change can take place.

The processing sequence is as follows:

  1. User starts to edit a field.
  2. The change is added to the input queue for Uniface.
  3. The Uniface Structure Editor take control and activates the startModification trigger.
  4. If this is successful (returns 0 in $status), the Structure Editor activates the lock trigger, which locks the occurrence in the database.
  5. If this is successful, the modification is allowed. If the processing in this trigger returns an error, the modifications are not applied.

Once the field has been changed, the user may go on to perform another action, such as moving to the next field. In this case, the Structure Editor executes the following sequence of triggers:

  1. validate trigger
  2. loseFocus trigger
  3. next trigger