Types of Events

Oracle Forms recognizes a predefined set of runtime events, each of which has a 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 Clicking a check box Pressing the Tab key

When-Button-Pressed When-Checkbox-Changed KEY-FN

Internal Processing Events

Internal events occur as a result of runtime processing. These events occur according to the Oracle Forms 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: Trigger Prefix Description

KeyOnPrePostWhen-

Fires in place of the standard action of a function key Fires in place of standard processing (used to replace or bypass a process) Fires on an event that occurs just before an action (for example, before a query is executed) Fires just after an action (for example, after a query is executed) Fires in addition to standard processing (used to augment functionality)

Event

Trigger Name

Enter the block Enter the Item Enter the record Leave the block Leave the item Leave the record Ready block for input Ready item for input Ready record for input Validate the item Validate the record

Pre-Block Pre-Text-Item Pre-Record Post-Block Post-Text-Item Post-Record When-New-Block-Instance When-New-Item-Instance When-New-Record-Instance When-Validate-Item When-Validate-Record

Pre-Triggers
Pre Trigger Pre-Block Pre-Commit Pre-Delete Use of Trigger Allow or disallow access to a block. Set variable values. Use a Pre-Commit trigger to perform an action, such as setting up special locking requirements, at any time a Database commit is going to occur. Use a Pre-Delete trigger to delete the detail record of a master record. Use a Pre-Delete trigger to prevent the deletion of a record if that record is the master record for detail records that still exist. Assign unique primary key from sequence. Restrict access to a form. Initialize global variables. Use a Pre-Insert trigger to perform the following tasks: Change item values Keep track of the date a record is created and store that in the record prior to committing. Use a Pre-Logon trigger to prepare the form for the logon procedure, particularly to a non-ORACLE data source. Use a Pre-Logout trigger to prepare the form for logging out from the data source, particularly a non-ORACLE data

Pre-Form

Pre-Insert

Pre-Logon Pre-Logout

Pre-Popup-Menu Pre-Query Pre-Record Pre-Select Pre-Text-Item

Pre-Update

source. If you call certain built-ins from within one of the Logout triggers, the results are undefined. For example, the COPY built-in cannot be called from a Pre-Logout trigger because Pre-Logout fires after the Leave the Form event. Because the form is no longer accessible at this point, the COPY operation is not possible. Use this trigger to enable or disable menu items on a pop-up menu before it is displayed. Use a Pre-Query trigger to modify the example record that determines which rows will be identified by the query. Use a Pre-Record trigger to keep a running total. Use a Pre-Select trigger to prepare a query prior to execution against a non-ORACLE data source. Derive a complex default value, based on other items previously entered into the same record. Record the current value of the text item for future reference, and store that value in a global variable or form parameter. Use a Pre-Update trigger to audit transactions.

Post-Triggers
Post-Block Use a Post-Block trigger to validate the block's current record; that is, the record that had input focus when the Leave the Block event occurred. Use this trigger to test a condition and prevent the user from leaving a block based on that condition. The Post-Change trigger is included only for compatibility with previous versions of Oracle Forms. Its use is not recommended in new applications Use a Post-Database-Commit trigger to perform an action anytime a database commit has occurred. Use a Post-Delete trigger to audit transactions. Use a Post-Form trigger for the following tasks: To clean up the form before exiting. For example, use a Post-Form trigger to erase any global variables that the form no longer requires. To display a message to the operator upon form exit. This trigger does not fire when the form is exited abnormally, for example, if validation fails in the form. Use a Post-Forms-Commit trigger to perform an action, such as updating an audit trail, anytime a database commit is about to occur. Use a Post-Insert trigger to audit transactions.

Post-Change Post-DatabaseCommit Post-Delete Post-Form

Post-FormsCommit Post-Insert

Post-Logon

Post-Logout

Post-Query

Post-Record

Post-Select Post-Text-Item Post-Update

Use a Post-Logon trigger to provide an event point for a task such as setting up a custom environment with special variables--to initialize on an application level rather than a form-by-form basis. You might accomplish this by initializing special global variables from this trigger. Use a Post-Logout trigger to audit or to perform tasks on an Oracle Forms application that does not require or affect the RDBMS or other data source. If you call certain built-ins from within one of the Logout triggers, the results are undefined. For example, you cannot call COPY from a Pre-Logout trigger because Pre-Logout fires after the Leave the Form event. Because the form is no longer accessible, a COPY operation is not possible. Use a Post-Query trigger to perform the following tasks: Populate control items or items in other blocks. Calculate statistics about the records retrieved by a query . Calculate a running total When you use a Post-Query trigger to SELECT non-base table values into control items, Oracle Forms marks each record as CHANGED, and so fires the When-Validate-Item trigger by default. You can avoid the execution of the When-Validate-Item trigger by explicitly setting the Status property of each record to QUERY in the Post-Query trigger. To set record status programmatically, use SET_RECORD_PROPERTY . Use a Post-Record trigger to perform an action whenever the operator or the application moves the input focus from one record to another. For example, to set a visual attribute for an item as the operator scrolls down through a set of records, put the code within this trigger. Use the Post-Select trigger to perform an action based on the outcome of the Select phase of query processing such as an action based on the number of records that match the query criteria. Use a Post-Text-Item trigger to calculate or change item values. Use a Post-Update trigger to audit transactions.

On-Triggers
On-Check-DeleteMaster On-Check-Unique On-Clear-Details On-Close Automatically Created. To perform the default processing from this trigger, call the CHECK_RECORD_UNIQUENESS built-in. Oracle Forms creates the On-Clear-Details trigger automatically when a Master/Detail block relation is defined. Use an On-Close trigger after using the On-Select or On-Fetch triggers, specifically, to close files, close cursors, and free memory. The On-Close trigger fires automatically when the ABORT_QUERY built-in is called from an On-Select trigger. To perform the default processing from this trigger, call the ENFORCE_COLUMN_SECURITY built-in. Use an On-Commit trigger to change the conditions of normal Oracle Forms commit processing to fit the particular requirements of a commit to a non-ORACLE database. Use an On-Count trigger to replace default Count Query processing in an application running against a nonORACLE data source. If you are replacing default processing, you can set the value of the Query Hits block property to indicate the number of records in the non-ORACLE data source that match the query criteria. Oracle Forms will display the query hits message (FRM-40355) even if the On-Count trigger fails to set the value of the Query Hits block property. In such a case, the message reports 0 records identified. Use an On-Delete trigger to replace the default Oracle Forms processing for handling deleted records during transaction posting. To perform the default Oracle Forms processing from this trigger, that is, to delete a record from your form or from the database, include a call to the DELETE_RECORD built-in. Use an On-Error trigger for the following purposes: to trap and recover from an error to replace a standard error message with a custom message Use the ERROR_CODE, ERROR_TEXT, ERROR_TYPE, DBMS_ERROR_TEXT, or DBMS_ERROR_CODE Built-in function in an On-Error trigger to identify a specific error condition. In most cases, On-Error triggers should be attached to the form, rather than to a block or item. Trapping certain errors at the block or item level can be difficult if these errors occur while Oracle Forms is performing internal navigation, such as during a Commit process. When you write an On-Fetch trigger to replace default fetch processing, the trigger must do the following: 1. Retrieve the appropriate number of records from the non-ORACLE data source, as indicated by the setting of

On-ColumnSecurity On-Commit On-Count

On-Delete

On-Error

On-Fetch

the Records_To_Fetch property. Create that number of queried records in the current block. Populate the records with the retrieved data. Create queried records from an On-Fetch trigger by calling the CREATE_QUERIED_RECORD built-in subprogram. While the query remains open, the On-Fetch trigger continues to fire as more records are needed in the block. This behavior continues: 1. Until no queried records are created in a single execution of the trigger. Failing to create any records signals an end-of-fetch to Oracle Forms, indicating that there are no more records to be retrieved. 2. Until the query is closed, either by the operator or programmatically through a call to ABORT_QUERY. 3. Until the trigger raises the built-in exception FORM_TRIGGER_FAILURE. To perform the default Oracle Forms processing from this trigger, include a call to the FETCH_RECORDS built-in. Do not use an ABORT_QUERY built-in in an On-Fetch trigger. ABORT_QUERY is not valid in an On-Fetch trigger, and produces inconsistent results. 2. 3. 4. On-Insert Use an On-Insert trigger to replace the default Oracle Forms processing for handling inserted records during transaction posting. To perform the default Oracle Forms processing from this trigger, include a call to the INSERT_RECORD built-in. Use an On-Lock trigger to replace the default Oracle Forms processing for locking rows. For example, for an application intended for use on a single-user system, use the On-Lock trigger to speed processing by bypassing all lock processing. Also, use On-Lock when accessing a non-ORACLE data source directly, not by way of Open Gateway. When the On-Lock trigger fires as a result of an operator trying to modify data, the trigger fires only the first time the operator tries to modify an item in the record. The trigger does not fire during subsequent modifications to items in the same record. In other words, for every row that is to be locked, the trigger fires once. To perform the default Oracle Forms processing from this trigger, include a call to the LOCK_RECORD built-in Use this trigger to lock underlying tables for non-updateable view. Use an On-Logon trigger to initiate a logon procedure to a non-ORACLE data source. Pre-Logon and Post-Logon triggers fire as part of the logon procedure. To create an application that does not require a data source, supply a NULL command to this trigger to bypass the connection to a data source. To perform the default Oracle Forms processing from this trigger, include a call to the LOGON built-in. Use an On-Logout trigger to replace the default logout processing either from the RDBMS or from a nonORACLE data source.

On-Lock

On-Logon

On-Logout

On-Message

On-PopulateDetails

On-Rollback On-Savepoint

On-Select

To perform the default Oracle Forms processing from this trigger, include a call to the LOGOUT built-in. If you call certain built-ins from within one of the Logout triggers, the results are undefined. For example, you cannot call the COPY built-in from a Pre-Logout trigger because Pre-Logout fires after the Leave the Form event. Because the form is no longer accessible, a COPY operation is not possible. To trap and respond to an informative message. To replace a standard informative message with a custom message. To exclude an inappropriate message Use the MESSAGE_CODE, MESSAGE_TEXT, MESSAGE_TYPE built-ins in an On-Message trigger to identify the occurrence of a specific message condition. If you use the On-Message trigger to trap a message so that it does not display on the message line, the GET_MESSAGE built-in does not return a value. To display the current message from this trigger, you must trap the message and explicitly write it to the display device. In most cases, On-Message triggers should be attached to the form, rather than to a block or item. Trapping certain errors at the block or item level can be difficult if these errors occur while Oracle Forms is performing internal navigation, such as during a Commit process. Use an On-Populate-Details trigger when you have established a Master/Detail relationship and you want to replace the default populate phase of a query. The On-Populate-Details trigger does not fire unless an On-Clear-Details trigger is present. If you are using the default Master/Detail functionality, Oracle Forms creates the necessary triggers automatically. However, if you are writing your own Master/Detail logic, be aware that the On-Clear-Details trigger must be present, even if it contains only the NULL statement. When Immediate coordination is set, this causes the details of the instantiated master to be populated immediately. Immediate coordination is the default. When Deferred coordination is set and this trigger fires, Oracle Forms marks the blocks as needing to be coordinated. If you intend to manage block coordination yourself, you can call the SET_BLOCK_PROPERTY (COORDINATION_STATUS) built-in. Use an On-Rollback trigger to replace standard Oracle Forms rollback processing. To perform default Oracle Forms processing from this trigger, include a call to the ISSUE_ROLLBACK built-in. To perform default Oracle Forms processing from this trigger, include a call to the ISSUE_SAVEPOINT built-in. In an On-Savepoint trigger, the Savepoint_Name application property returns the name of the next savepoint that Oracle Forms would issue by default, if no On-Savepoint trigger were present. In an On-Rollback trigger, Savepoint_Name returns the name of the savepoint to which Oracle Forms would roll back. Suppress default savepoint processing by setting the Savepoint Mode form document property to Off. When Savepoint Mode is Off, Oracle Forms does not issue savepoints and, consequently, the On-Savepoint trigger never fires Use an On-Select trigger to open and execute the database cursor. Specifically, use this trigger when you are retrieving data from a non-ORACLE data source. The On-Select trigger can be used in conjunction with the On-Fetch trigger to

On-SequenceNumber

On-Update

replace the processing that normally occurs in the EXECUTE_QUERY built-in subprogram. To perform the default Oracle Forms processing from this trigger, include a call to the SELECT_RECORDS built-in. When a SEQUENCE is used as a default item value, Oracle Forms queries the database to get the next value from the SEQUENCE whenever the Create Record event occurs. Suppress or override this functionality with an On-SequenceNumber trigger. To perform the default Oracle Forms processing from this trigger, call the GENERATE_SEQUENCE_NUMBER built-in. Use an On-Update trigger to replace the default Oracle Forms processing for handling updated records during transaction posting. To perform the default Oracle Forms processing from this trigger, include a call to the UPDATE_RECORD built-in.

When-Triggers
When-Button-Pressed When-Checkbox-Changed When-Clear-Block When-Create-Record When-Database-Record When-Form-Navigate When-Image-Activated When-Image-Pressed When-List-Activated When-List-Changed When-Mouse-Click When-Mouse-DoubleClick When-Mouse-Down When-Mouse-Enter When-Mouse-Leave When-Mouse-Move When-Mouse-Up When-New-Block-Instance When-New-Form-Instance When-New-Item-Instance When-New-Record-Instance

When-Radio-Changed When-Remove-Record When-Tab-Page-Changed When-Timer-Expired When-Validate-Item When-Validate-Record When-Window-Activated When-Window-Closed When-Window-Deactivated When-Window-Resized

Online English

http://www.englishleap.com/english-course
http://www.lumosity.com

Trigger Types Block processing triggers

Block processing triggers fire in response to events related to record management in a block. Trigger When-Create-Record When-Clear-Block When-Database-Record When-Remove-Record Typical Usage Perform an action whenever Oracle Forms 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. Perform an action whenever Oracle Forms flushes the current block; that is, removes all records from the block. Perform an action whenever Oracle Forms changes a record's status to Insert or Update, thus indicating that the record should be processed by the next COMMIT_FORM operation. 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.

Interface Event triggers When-Button-Pressed When-Checkbox-Changed When-Image-Activated When-Image-Pressed Key- [all] When-Radio-Changed

When-Window-Closed

When-Window-Deactivated

When-Window-Resized

Initiate an action whenever the operator double-clicks an image item. Initiate an action whenever an operator clicks on an image item. Replace the default function associated with a function key. For example, you can define a KeyEXIT trigger to replace the default functionality of the [Help] key. Initiate an action when an operator changes the current radio button selected in a radio group item. WhenTimer-Expired Initiate an action whenever an operator closes a window with the window manager's Close command. Initiate an action whenever a window is deactivated as a result of another window becoming the active window. Initiate an action whenever a window is resized, either by the operator or programmatically.

Initiate an action when a programmatic timer expires. When-Window-Activated Initiate an action whenever an operator or the application activates a window.

Key triggers Master-Detail triggers Message-Handling triggers Mouse Event triggers Navigation triggers On triggers Post triggers Pre triggers Query-Time triggers Stored Procedure triggers Transactional triggers Validation triggers When triggers

Triggers in Oracle Forms

Triggers are blocks of PL/SQL code that are written to perform tasks when a specific event occurs within an application. In effect, an Oracle Forms 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.

Block Processing Triggers:

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

When-Create-Record Perform an action whenever Oracle Forms attempts to create a new record in a block. When-Clear-Block Perform an action whenever Oracle Forms flushes the current block; that is, removes all records from the block. When-Database-Record Perform an action whenever Oracle Forms changes a records status to Insert or Update, thus indicating that the record should be processed by the next COMMIT_FORM operation.

Interface Event Triggers:

Interface event triggers fire in response to events that occur in the form interface. Some of these triggers, such as When-ButtonPressed, 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.

When-Button-Pressed Initiate an action when an operator selects a button, either with the mouse or through keyboard selection. 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. When-Radio-Changed Initiate an action when an operator changes the current radio button selected in a radio group item. 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 managers Close command. When-Window-Deactivated Initiate an action whenever a window is deactivated as a result of another window becoming the active window.

Master/Detail Triggers:
Oracle Forms 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.

On-Check-Delete-Master Fires when Oracle Forms attempts to delete a record in a block that is a master block in a master/detail relation. On-Clear-Details Fires when Oracle Forms 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 Oracle Forms 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.

Message-Handling Triggers:
Oracle Forms automatically issues appropriate error and informational messages in response to runtime events. Message handling triggers fire in response to these default messaging events.

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 Oracle Forms with a custom message.

Validation Triggers:
Validation triggers fire when Oracle Forms validates data in an item or record. Oracle Forms performs validation checks during navigation that occurs in response to operator input, programmatic control, or default processing, such as a Commit operation.

When-Validate-Item When-Validate-Record

Navigational Triggers:
Navigational triggers fire in response to navigational events. Navigational triggers can be further sub-divided into two categories: Preand Post- triggers, and When-New-Instance triggers. Pre- and Post- Triggers fire as Oracle Forms navigates internally through

different levels of the object hierarchy. When-New-Instance-Triggers fire at the end of a navigational sequence that places the input focus on a different item.

Pre-Form Perform an action just before Oracle Forms navigates to the form from outside the form, such as at form startup. Pre-Block Perform an action before Oracle Forms navigates to the block level from the form level. Pre-Record Perform an action before Oracle Forms navigates to the record level from the block level. Pre-Text-Item Perform an action before Oracle Forms navigates to a text item from the record level. Post-Text-Item Manipulate an item when Oracle Forms leaves a text item and navigates to the record level. Post-Record Manipulate a record when Oracle Forms leaves a record and navigates to the block level. Post-Block Manipulate the current record when Oracle Forms leaves a block and navigates to the form level. Post-Form Perform an action before Oracle Forms navigates to outside the form, such as when exiting the form. When-New-Form-Instance Perform an action at form start-up. (Occurs after the Pre-Form trigger fires). When-New-Block-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. When-New-Item-Instance Perform an action immediately after the input focus moves to a different item.

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

On-Delete On-Insert On-Update On-Logon On-Logout Post-Database-Commit Post-Delete Post-Insert Post-Update Pre-Commit Pre-Delete Pre-Insert

Pre-Update

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

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.