Oracle Forms

Trigger Property: Execution Hierarchy:

      If we write same trigger (for ex: WHEN-NEW-ITEM-INSTANCE) in all three levels and set up this property as Override/Before/After, which level trigger will fire.

            O Override
            B Before
            A After

Form Block Item Result
O/B/A O/B/A O Item level
O O B Item Level, Block Level
O O A Block Level, Item Level
O B B Item Level, Block Level, Form Level
O B A Block Level, Form Level, Item Level
O A A Form Level, Block Level, Item Level
O A B Item Level, Form Level, Block Level
B B B Item Level, Block Level, Form Level
A A A Form Level, Block Level, Item Level
A B A Block Level, Form Level, Item Level
A A B Item Level, Form Level, Block Level
A B B Item Level, Block Level, Form Level

More Detail Information on Triggers

Block Processing Triggers:

      Block processing triggers fire in response to events related to record management in a block.

Trigger Typical Usage
When-Create-Record Perform an action whenever Form Builder attempts to create a new record in a block. For example, to set complex, calculated, or data-driven default values that must be specified at runtime, rather than design time.
When-Clear-Block Perform an action whenever Form Builder flushes the current block; that is, removes all records from the block.
When-Database-Record Perform an action whenever Form Builder changes a record's status to Insert or Update, thus indicating that the record should be processed by the next COMMIT_FORM operation.
When-Remove-Record Perform an action whenever a record is cleared or deleted. For example, to adjust a running total that is being calculated for all of the records displayed in a block.

Master/Detail Triggers:

      Form Builder generates master/detail triggers automatically when a master/detail relation is defined between blocks. The default master/detail triggers enforce coordination between records in a detail block and the master record in a master block. Unless developing custom block-coordination schemes, you do not need to define these triggers. Instead, simply create a relation object, and let Form Builder generate the triggers required to manage coordination between the master and detail blocks in the relation.

Trigger Typical Usage
On-Check-Delete-Master Fires when Form Builder attempts to delete a record in a block that is a master block in a master/detail relation.
On-Clear-Details Fires when Form Builder needs to clear records in a block that is a detail block in a master/detail relation because those records no longer correspond to the Current record in the master block.
On-Populate-Details Fires when Form Builder needs to fetch records into a block that is the detail block in a master/detail relation so that detail records are synchronized with the current record in the master block.

Interface Event Triggers:

      Interface event triggers fire in response to events that occur in the form interface. Some of these trigger, such as When-Button-Pressed, fire only in response to operator input or manipulation. Others, like When-Window-Activated, can fire in response to both operator input and programmatic control.

TriggerTypical Usage
When-Button-Pressed Initiate an action when an operator selects a button, either with the mouse or through keyboard election.
When-Checkbox-Changed Initiate an action when the operator toggles the state of a check box, either with the mouse or through keyboard selection.
When-Image-Activated Initiate an action whenever the operator double-clicks an image item.
When-Image-Pressed Initiate an action whenever an operator clicks on an image item.
Key- [all] Replace the default function associated with a function key. For example, you can define a Key-EXIT trigger to replace the default functionality of the [Help] key.
When-Radio-Changed Initiate an action when an operator changes the current radio button selected in a radio group item.
When-Timer-Expired Initiate an action when a programmatic timer expires.
When-Window-Activated Initiate an action whenever an operator or the application activates a window.
When-Window-Closed Initiate an action whenever an operator closes a window with the window manager's Close command.
When-Window-Deactivated Initiate an action whenever a window is deactivated as a result of another window becoming the active window.
When-Window-Resized Initiate an action whenever a window is resized, either by the operator or programmatically.

Message-Handling Triggers:

      Form Builder automatically issues appropriate error and informational messages in response to runtime events. Message handling triggers fire in response to these default messaging events.

Trigger Typical Usage
On-Error Replace a default error message with a custom error message, or to trap and recover from an error.
On-Message To trap and respond to a message; for example, to replace a default message issued by Form Builder with a custom message.

Mouse Event Trigger:

      Creating a mouse event trigger to respond to a mouse event allows you to initiate an action whenever the specified mouse event occurs.

Trigger Typical Usage
When-Mouse-Down Initiates an action when the operator presses down the mouse button within an item or canvas.
When-Mouse-Up Initiates an action when the operator presses down and releases the mouse button within an item or canvas.
When-Mouse-Click Initiates an action when the operator clicks the mouse within an item or canvas. Clicking the mouse consists of the mouse down and up events.
When-Mouse-DoubleClick Initiates an action when the operator double-clicks the mouse within an item or canvas. Double-clicking the mouse consists of the mouse click, mouse down, and mouse up events.
When-Mouse-Enter Initiates an action when the operator moves the mouse into an item or canvas.
When-Mouse-Leave Initiates an action when the operator moves the mouse out of an item or canvas.
When-Mouse-Move Initiates an action when the operator moves the mouse within an item or canvas.

Navigational Triggers:

      Navigational triggers fire in response to navigational events. For instance, when the operator clicks on a text item in another block, navigational events occur as Form Builder moves the input focus from the current item to the target item.

      Navigational events occur at different levels of the Form Builder object hierarchy (Form, Block, Record, Item). Navigational triggers can be further sub-divided into two categories: Pre- and Post- triggers, and When-New-Instance triggers.

      Pre- and Post- Triggers fire as Form Builder navigates internally through different levels of the object hierarchy. As you might expect, these triggers fire in response to navigation initiated by an operator, such as pressing the [Next Item] key. However, be aware that these triggers also fire in response to internal navigation that Form Builder performs during default processing. To avoid unexpected results, you must consider such internal navigation when you use these triggers.

Trigger Typical Usage
Pre-Form Perform an action just before Form Builder navigates to the form from "outside" the form, such as at form startup.
Pre-Block Perform an action before Form Builder navigates to the block level from the form level.
Pre-Record Perform an action before Form Builder navigates to the record level from the block level.
Pre-Text-Item Perform an action before Form Builder navigates to a text item from the record level.
Post-Text-Item Manipulate an item when Form Builder leaves a text item and navigates to the record level.
Post-Record Manipulate a record when Form Builder leaves a record and navigates to the block level.
Post-Block Manipulate the current record when Form Builder leaves a block and navigates to the form level.
Post-Form Perform an action before Form Builder navigates to "outside" the form, such as when exiting the form.

When-New-Instance-Triggers:

      Fire at the end of a navigational sequence that places the input focus on a different item. Specifically, these triggers fire just after Form Builder moves the input focus to a different item, when the form returns to a quiet state to wait for operator input.Unlike the Pre- and Post- navigational triggers, the When-New-Instance triggers do not fire in response to internal navigational events that occur during default form processing.

Trigger Typical Usage
When-New-Form-Instance Perform an action at form start-up. (Occurs after the Pre-Form trigger fires).
When-New-Form-Instance Perform an action immediately after the input focus moves to an item in a block other than the block that previously had input focus.
When-New-Record-Instance Perform an action immediately after the input focus moves to an item in a different record. If the new record is in a different block, fires after the When-New-Block-Instance trigger, but before the When-New-Item-Instance trigger.
When-New-Item-Instance Perform an action immediately after the input focus moves to a different item. If the new item is in a different block, fires after the When-New-Block-Instance trigger.

Query-Time Triggers:

      Query-time triggers fire just before and just after the operator or the application executes a query in a block.

Trigger Typical Usage
Pre-Query Validate the current query criteria or provide additional query criteria programmatically, just before sending the SELECT statement to the database.
Post-Query Perform an action after fetching a record, such as looking up values in other tables based on a value in the current record. Fires once for each record fetched into the block.

Transactional Triggers:

      Transactional triggers fire in response to a wide variety of events that occur as a form interacts with the data source.

Trigger Typical Usage
On-Delete Replace the default Form Builder processing for handling deleted records during transaction posting.
On-Insert Replace the default Form Builder processing for handling inserted records during transaction posting.
On-Lock Replace the default Form Builder processing for locking rows in the database.
On-Logon Replace the default Form Builder processing for connecting to ORACLE, especially for a form that does not require a database connection or for connecting to a non-ORACLE data source.
On-Logout Replace the default Form Builder processing for logout from ORACLE.
On-Update Replace the default Form Builder processing for handling updated records during transaction posting.
Post-Database-CommitAugment default Form Builder processing following a database commits.
Post-Delete Audit transactions following the deletion of a row from the database.
Post-Forms-Commit Augment the default Form Builder commit statement prior to committing a transaction.
Post-Insert Audit transactions following the insertion of a row in the database.
Post-Update Audit transactions following the updating of a row in the database.
Pre-Commit Perform an action immediately before the Post and Commit Transactions process, when Form Builder determines that there are changes in the form to post or to commit.
Pre-Delete Manipulate a record prior to its being deleted from the database during the default Post and Commit Transactions process; for example, to prevent deletion of the record if certain conditions exist.
Pre-Insert Manipulate a record prior to its being inserted in the database during the default Post and Commit Transactions process.
Pre-Update Validate or modify a record prior to its being updated in the database during the default Post and Commit Transactions process.

Note: This is only a partial list of the transactional triggers available. Many of the triggers not shown here are On-event triggers that exist primarily for applications that will run against a non-ORACLE data source.

User-Named Triggers:

      A user-named trigger is one that has a unique, user-supplied name. Because its name does not correspond to any Form Builder event, a user-named trigger can only be executed by calling it from within a built-in trigger, menu item command, or user-named subprogram. To call a user-named trigger, use the EXECUTE_TRIGGER built-in procedure. This procedure takes a parameter that names the trigger to be fired:

      Execute_Trigger('my_user_named_trigger');

      User-named triggers are required only in special situations. For most applications, writing a user-named subprogram and then calling that from a trigger or menu item command is preferred.

                                                                                                                             Previous     Next