Oracle Forms

Event Types:

      Corresponding built in trigger. When you add code to an application by writing a trigger, it is important to decide what event should fire the trigger. The event you choose determines the name assigned to the trigger.

Interface Events :

      When selecting triggers, it is important to understand precisely when events occur, both in relation to other events, and in relation to form processing. Some events are external interface events, and their occurrence is immediately apparent. Examples of such events, and their corresponding triggers, include the following:

Event Trigger Name
Pressing a button When-Button-Pressed
Clicking a check box When-Checkbox-Changed
Pressing the Tab key KEY-FN

Internal Processing Events:

      Internal events occur as a result of runtime processing. These events occur according to the Form Builder processing model.

      Consider a form with two blocks, Block A and Block B, with text items in each block. On GUI platforms, operators can move the input focus from a text item in Block A to a text item in Block B by clicking the target item with a mouse. Although this operation involves only one interface action (the mouse-click in the target item), it actually sets off a series of internal processing events, each of which has one or more corresponding triggers:

Event Trigger Name
Validate the item When-Validate-Item
Leave the item Post-Text-Item
Validate the record When-Validate-Record
Leave the record Post-Record
Leave the block Post-Block
Enter the block Pre-Block
Enter the record Pre-Record
Enter the Item Pre-Text-Item
Ready block for input When-New-Block-Instance
Ready record for input When-New-Record-Instanc
Ready item for input When-New-Item-Instance

      It is important to understand that navigational events such as "Leave the Item" and "Enter the Block" occur as a result of internal form processing navigation. These events occur as Form Builder validates data in the form and "navigates" through the object hierarchy to move from one item to another.

      In the example, to move the input focus from a source item in one block to a target item in another, Form Builder first validates the value in the source item, then "enters the record" to validate all of the items in the record, then leaves the record and "enters the block," and so on, finally ending up in the target item.

      The Form Builder processing model enforces the integrity of data at the item, record, block, and form level. The rich assortment of events to which can be responded with trigger code gives complete control over every aspect of an application. Processes and Sub-Processes

      A process is a series of individual, related events that occurs during a specific Form Builder Runform operation. The previous example described a navigational process. Other processes involve validation and database transactions. For example, the Post and Commit Transaction process includes a complex series of events and sub-processes.

About Triggers and Events:

      Triggers are blocks of PL/SQL code that are written to perform tasks when a specific event occurs within an application. In effect, a Form Builder trigger is an event-handler written in PL/SQL to augment (or occasionally replace) the default processing behavior. Every trigger has a name, and contains one or more PL/SQL statements. A trigger encapsulates PL/SQL code so that it can be associated with an event and executed and maintained as a distinct object. When Form Builder responds to an event by executing the code in a trigger, that trigger is said to have "fired." Most form applications include numerous triggers that fire in response to a variety of events.

      A trigger must be attached to a specific object in the form, either an item, a block, or the form itself. The object to which a trigger is attached defines the scope of the trigger, and so helps Form Builder decide which trigger to fire when the corresponding event occurs. Not all triggers are relevant to all objects. For example a When-Button-Pressed trigger would not be attached to a display item.

      Trigger names correspond to pre-defined runtime events. For example, the When-Button-Pressed trigger corresponds to the Button Pressed event, which occurs when an operator selects a button. The name of the trigger establishes the association between the event and the trigger code; when operators click on a button with a mouse, Form Builder responds by executing the code in the When-Button-Pressed trigger.

      For example, in a form with three buttons, each button has a When-Button-Pressed trigger attached to it, and each trigger contains different PL/SQL statements. When an operator selects one of the buttons, that is, when the Button Pressed event occurs, Form Builder responds by firing only the When-Button-Pressed trigger attached to the selected button. The When-Button-Pressed triggers attached to the other two buttons are outside the scope of the event, and so are ignored.