System Variables Toutorial

System Variables

2.1 About System Variables

A system variable is an Oracle Forms variable that keeps track of an internal Oracle Forms state. You can reference the value of a system variable to control the way an application behaves.

Oracle Forms maintains the values of system variables on a per form basis. That is, the values of all system variables correspond only to the current form. The following list presents the names of the available system variables

2.1.1 List of system variables

2.1.1.1 SYSTEM.BLOCK_STATUS

Represents the status of the block where the cursor is located, or the current block during trigger processing. The value can be one of three character strings:

• CHANGED -Indicates that the block contains at least one Changed record.

• NEW - Indicates that the block contains only New records.

• QUERY - Indicates that the block contains only Valid records that have been retrieved from the database.

2.1.1.2 SYSTEM.COORDINATION_OPERATION

This system variable works with its companion SYSTEM.MASTER_BLOCK to help an On-Clear-Details trigger determine what type of coordination-causing operation fired the trigger, and on which master block of a master-detail relation.

2.1.1.3 SYSTEM.CURRENT_BLOCK

The value that the SYSTEM.CURRENT_BLOCK system variable represents depends on the current navigation unit:

• If the current navigation unit is the block, record, or item (as in the Pre- and Post- Item, Record, and Block triggers), the value of SYSTEM.CURRENT_BLOCK is the name of the block that Oracle Forms is processing or that the cursor is in.

• If the current navigation unit is the form (as in the Pre- and Post-Form triggers), the value of SYSTEM.CURRENT_BLOCK is NULL.

The value is always a character string.

Note: SYSTEM.CURRENT_BLOCK is included for compatibility with previous versions. Oracle Corporation recommends that you use SYSTEM.CURSOR_BLOCK and SYSTEM.TRIGGER_BLOCK instead.

2.1.1.4 SYSTEM.CURRENT_DATETIME

Is a variable representing the operating system date. The value is a CHAR string in the following format:

DD-MON-YYYY HH24:MI:SS

2.1.1.5 SYSTEM.CURRENT_FORM

Represents the name of the form that Oracle Forms is executing. The value is always a character string.

2.1.1.6 SYSTEM.CURRENT_ITEM

The value that the SYSTEM.CURRENT_ITEM system variable represents depends on the current navigation unit:

• If the current navigation unit is the item (as in the Pre- and Post-Item triggers), the value of SYSTEM.CURRENT_ITEM is the name of the item that Oracle Forms is processing or that the cursor is in. The returned item name does not include a block name prefix.

• If the current navigation unit is the record, block, or form (as in the Pre- and Post- Record, Block, and Form triggers), the value of SYSTEM.CURRENT_ITEM is NULL.

The value is always a character string.

Note: SYSTEM.CURRENT_ITEM is included for compatibility with previous versions. Oracle Corporation recommends that you use SYSTEM.CURSOR_ITEM or SYSTEM.TRIGGER_ITEM instead.

2.1.1.7 SYSTEM.CURRENT_VALUE

Represents the value of the item that is registered in SYSTEM.CURRENT_ITEM.

The value is always a character string.

Note: SYSTEM.CURRENT_VALUE is included for compatibility with previous versions. Oracle Corporation recommends that you use SYSTEM.CURSOR_ITEM and SYSTEM.CURSOR_VALUE instead.

2.1.1.8 SYSTEM.CURSOR_BLOCK

The value that the SYSTEM.CURSOR_BLOCK system variable represents depends on the current navigation unit:

• If the current navigation unit is the block, record, or item (as in the Pre- and Post- Item, Record, and Block triggers), the value of SYSTEM.CURSOR_BLOCK is the name of the block where the cursor is located. The value is always a character string.

• If the current navigation unit is the form (as in the Pre- and Post-Form triggers), the value of SYSTEM.CURSOR_BLOCK is NULL.

2.1.1.9 SYSTEM.CURSOR_ITEM

Represents the name of the block and item, block.item, where the input focus (cursor) is located.

The value is always a character string.

2.1.1.10 SYSTEM.CURSOR_RECORD

Represents the number of the record where the cursor is located. This number represents the record's current physical order in the block's list of records. The value is always a character string.

2.1.1.11 SYSTEM.CURSOR_VALUE

Represents the value of the item where the cursor is located. The value is always a character string.

2.1.1.12 SYSTEM.CUSTOM_ITEM_EVENT

Stores the name of the event fired by a VBX control.

2.1.1.13 SYSTEM.CUSTOM_ITEM_EVENT_PARAMETERS

Stores the supplementary arguments for an event fired by a VBX control.

2.1.1.14 SYSTEM.DATE_THRESHOLD*

Represents the database date requery threshold. This variable works in conjunction with the three system variables $$DBDATE$$, $$DBDATETIME$$, and $$DBTIME$$, and controls how often Oracle Forms synchronizes the database date with the RDBMS. The value of this variable must be specified in the following format: MI:SS .

Because frequent RDBMS queries can degrade performance, it is best to keep this value reasonably high. However, keep in mind that if the value is not synchronized often enough, some time discrepancy can occur. In addition, if you are building a client-server application, the performance implications of SYSTEM.DATE_THRESHOLD could vary depending on the complexity of your network configuration.

2.1.1.15 SYSTEM.EFFECTIVE_DATE*

Represents the effective database date. The variable value must always be in the following format:

DD-MON-YYYY HH24:MI:SS .

2.1.1.16 SYSTEM.EVENT_WINDOW

The SYSTEM.EVENT_WINDOW system variable represents the name of the last window that was affected by an action that caused one of the window event triggers to fire. The following triggers cause this variable to be updated:

• WHEN-WINDOW-ACTIVATED

• WHEN-WINDOW-CLOSED

• WHEN-WINDOW-DEACTIVATED

• WHEN-WINDOW-RESIZED

From within these triggers, you can assign the value of the variable to any of the following:

• global variable

• parameter

• variable

• item, including a null canvas item

2.1.1.17 SYSTEM.FORM_STATUS

Represents the status of the current form. The value can be one of three character strings:

• CHANGED - Indicates that the form contains at least one block with a Changed record. The value of SYSTEM.FORM_STATUS becomes CHANGED only after at least one record in the form has been changed and the associated navigation unit has also changed.

• NEW - Indicates that the form contains only New records.

• QUERY - Indicates that a query is open. The form contains at least one block with QUERY records and no blocks with CHANGED records.

2.1.1.18 SYSTEM.LAST_FORM

Represents the form module ID of the previous form in a multi-form application, where multiple forms have been invoked using OPEN_FORM. The value can be one of two character strings: either the form module ID or NULL.

2.1.1.19 SYSTEM.LAST_QUERY

Represents the query SELECT statement that Oracle Forms most recently used to populate a block during the current Run form session. The value is always a character string.

2.1.1.20 SYSTEM.LAST_RECORD

Indicates whether the current record is the last record in a block's list of records. The value is one of the following two CHAR values:

• TRUE - Indicates that the current record is the last record in the current block's list of records.

• FALSE - Indicates that the current record is not the last record in the current block's list of records.

2.1.1.21 SYSTEM.MASTER_BLOCK

This system variable works with its companion SYSTEM.COORDINATION_OPERATION to help an On-Clear-Details trigger determine what type of coordination-causing operation fired the trigger, and on which master block of a master-detail relation. The values of the two system variables remain constant throughout the clearing phase of any block synchronization. SYSTEM.MASTER_BLOCK represents the name of the driving master block, and SYSTEM.COORDINATION_OPERATION represents the coordination-causing event that occurred on the master block.

More details are in the description for SYSTEM.COORDINATION_OPERATION.

2.1.1.22 SYSTEM.MESSAGE_LEVEL*

Represents one of the following message severity levels: 0, 5, 10, 15, 20, or 25. The value is always a character string.

During a Runform session, Oracle Forms suppresses all messages with a severity level that is the same or lower (less severe) than the indicated severity level.

Assign a value to the SYSTEM.MESSAGE_LEVEL system variable with standard PL/SQL syntax:

:System.Message_Level := value;

The legal values for SYSTEM.MESSAGE_LEVEL are 0, 5, 10, 15, 20, and 25. Oracle Forms does not suppress prompts or vital error messages, no matter what severity level you select.

2.1.1.23 SYSTEM.MODE

SYSTEM.MODE indicates whether the form is in Normal, Enter Query, or Fetch Processing mode. The value is always a character string.

• NORMAL - Indicates that the form is currently in normal processing mode.

• ENTER-QUERY - Indicates that the form is currently in Enter Query mode.

• QUERY - Indicates that the form is currently in fetch processing mode, meaning that a query is currently being processed.

2.1.1.24 SYSTEM.MOUSE_BUTTON_PRESSED

Indicates the number of the button that was clicked. Mouse button support is limited to buttons 1 and 2 (left or middle) on a three button mouse. The value is always a character string.

2.1.1.25 SYSTEM.MOUSE_BUTTON_SHIFT_STATE

Indicates the key that was pressed during the click, such as SHIFT, ALT, or CONTROL. The value is always a character string.

2.1.1.26 SYSTEM.MOUSE_CANVAS

If the mouse is in a canvas, SYSTEM.MOUSE_CANVAS represents the name of that canvas as a CHAR value. If the mouse is in an item, this variable represents the name of the canvas containing the item.

SYSTEM.MOUSE_CANVAS is NULL if:

• the mouse is not in a canvas

• the platform is non-GUI

2.1.1.27 SYSTEM.MOUSE_FORM

If the mouse is in a form module, SYSTEM.MOUSE_FORM represents the name of that form module as a CHAR value. For example, if the mouse is in Form_Module1, the value for SYSTEM.MOUSE_ITEM is FORM_MODULE1.

Note: SYSTEM.MOUSE_FORM is NULL if the platform is not a GUI platform.

2.1.1.28 SYSTEM.MOUSE_ITEM

If the mouse is in an item, SYSTEM.MOUSE_ITEM represents the name of that item as a CHAR value. For example, if the mouse is in Item1 in Block2, the value for SYSTEM.MOUSE_ITEM is :BLOCK2.ITEM1.

SYSTEM.MOUSE_ITEM is NULL if:

• the mouse is not in an item

• the platform is not a GUI platform

2.1.1.29 SYSTEM.MOUSE_RECORD

If the mouse is in a record, SYSTEM.MOUSE_RECORD represents that record's record number as a CHAR value.

Note: SYSTEM.MOUSE_RECORD is 0 if the mouse is not in an item (and thus, not in a record).

2.1.1.30 SYSTEM.MOUSE_RECORD_OFFSET

If the mouse is in a record, SYSTEM.MOUSE_RECORD_OFFSET represents the offset from the first visible record as a CHAR value.

For example, if the mouse is in the second of five visible records in a multi-record block, SYSTEM.MOUSE_RECORD_OFFSET is 2. (SYSTEM.MOUSE_RECORD_OFFSET uses a 1-based index).

Note: SYSTEM.MOUSE_RECORD_OFFSET is 0 if the mouse is not in an item (and thus, not in a record).

2.1.1.31 SYSTEM.MOUSE_X_POS

Represents (as a CHAR value) the x coordinate of the mouse in the units of the current form coordinate system. If the mouse is in an item, the value is relative to the upper left corner of the item's bounding box. If the mouse is on a canvas, the value is relative to the upper left corner of the canvas.

Note: SYSTEM.MOUSE_X_POS is always NULL on character mode platforms.

2.1.1.32 SYSTEM.MOUSE_Y_POS

Represents (as a CHAR value) the y coordinate of the mouse, using units of the current coordinate system. If the mouse is in an item, the value is relative to the upper left corner of the item's bounding box. If the mouse is on a canvas, the value is relative to the upper left corner of the canvas.

Note: SYSTEM.MOUSE_Y_POS is always NULL on character mode platforms.

2.1.1.33 SYSTEM.RECORD_STATUS

Represents the status of the record where the cursor is located. The value can be one of four character strings:

• CHANGED - Indicates that a queried record's validation status is Changed.

• INSERT - Indicates that the record's validation status is Changed and that the record does not exist in the database.

• NEW - Indicates that the record's validation status is New.

• QUERY - Indicates that the record's validation status is Valid and that it was retrieved from the database.

2.1.1.34 SYSTEM.SUPPRESS_WORKING*

suppresses the "Working..." message in Runform, in order to prevent the screen update usually caused by the display of the "Working..." message. The value of the variable is one of the following two CHAR values:

• TRUE - Prevents Oracle Forms from issuing the "Working..." message.

• FALSE - Allows Oracle Forms to continue to issue the "Working..." message.

2.1.1.35 SYSTEM.TRIGGER_BLOCK

Represents the name of the block where the cursor was located when the current trigger initially fired. The value is NULL if the current trigger is a Pre- or Post-Form trigger. The value is always a character string.

2.1.1.36 SYSTEM.TRIGGER_ITEM

Represents the item (BLOCK.ITEM) in the scope for which the trigger is currently firing. When referenced in a key trigger, it represents the item where the cursor was located when the trigger began. The value is always a character string.

2.1.1.37 SYSTEM.TRIGGER_RECORD

Represents the number of the record that Oracle Forms is processing. This number represents the record's current physical order in the block's list of records. The value is always a character string.

All system variables, except the four indicated with an asterisk (*), are read-only variables. These four variables are the only system variables to which you can explicitly assign values.

2.1.2 Date and Time System Default Values

Oracle Forms also supplies six special default values -- $$DATE$$, $$DATETIME$$, $$TIME$$, $$DBDATE$$, $$DBDATETIME$$, and $$DBTIME$$ -- that supply date and time information and have special restrictions on their use:

• If you're building client/server applications, consider the performance implications of going across the network to get date and time information.

• If you're accessing a non-ORACLE datasource, avoid using $$DBDATE$$ and $$DBDATETIME$$. Instead, use a When-Create-Record trigger to select the current date in a datasource-specific manner.

• Use $$DATE$$, $$DATETIME$$, and $$TIME$$ to obtain the local system date/time; use $$DBDATE$$, $$DBDATETIME$$, and $$DBTIME$$ to obtain the database date/time, which may differ from the local system date/time if, for example, you're connecting to a remote database in a different time zone.

• Use these variables only to set the value of the Default Value, Range Low Value or Range High Value property.

2.1.2.1 $$DATE$$

Retrieves the current operating system date. You can use $$DATE$$ to designate a default value or range for a text item using the Default or Range property. The text item must be of the CHAR, DATE, or DATETIME data type. You also can use $$DATE$$ as a default value for form parameters. In this case, the parameter's value is computed once, at form startup.

2.1.2.2 $$DATETIME$$

Retrieves the current operating system date and time. You can use $$DATETIME$$ to designate a default value or range for a text item using the Default or Range property. The text item must be of the CHAR or DATETIME data type. You also can use $$DATETIME$$ as a default value for form parameters. In this case, the parameter's value is computed once, at form startup.

The difference between $$DATE$$ and $$DATETIME$$ is that the time component for $$DATE$$ is always fixed to 00:00:00, compared to $$DATETIME$$, which includes a meaningful time component, such as 09:17:59.

Note: Do not use $$DATETIME$$ instead of $$DATE$$ unless you plan to specify the time component. If, for example, you use $$DATETIME$$ with the default DATE format mask of DD-MON-YY, you would be committing values to the database that the user would not see, because the format mask does not include a time component. Then, because you had committed specific time information, when you later queried on date, the values would not match and you would not return any rows.

2.1.2.3 $$DBDATE$$

Retrieves the current database date. You can use $$DBDATE$$ to designate a default value or range for a text item using the Default or Range property. The text item must be of the CHAR, DATE, or DATETIME data type.

2.1.2.4 $$DBDATETIME$$

Retrieves the current date and time from the local database. You can use $$DBDATETIME$$ to designate a default value or range for a text item using the Default or Range property. The text item must be of the CHAR or DATETIME data type.

2.1.2.5 $$DBTIME$$

Retrieves the current time from the local database. You can use $$DBTIME$$ to designate a default value or range for a text item using the Default or Range property. The text item must be of the CHAR or TIME data type.

2.1.2.6 $$TIME$$

Retrieves the current operating system time. You can use $$TIME$$ to designate a default value or range for a text item using the Default or Range property. The text item must be of the CHAR or TIME data type.

You also can use $$TIME$$ as a default value for form parameters. In this case, the parameter's value is computed once, at form startup.

2.1.3 Local Variables

Because system variables are derived, if the value is not expected to change over the life of the trigger, you can save the system value in a local variable and use the local variable multiple times.

Trigger इवेंट Toutorial

1. Triggers

1.1 About Triggers and Processes

Triggers are blocks of PL/SQL code that you write to perform specific tasks. There are pre-defined runtime events for which you can create triggers. Trigger names correspond to these events. For ease of description, the terms events and triggers are synonymous in this chapter. In effect, an Oracle Forms trigger is an event-handler written in PL/SQL to augment (or occasionally replace) the default processing behavior.

A process is a series of individual, related events that occurs during a specific Oracle Forms Runform operation. Oracle Forms includes navigational, validation, and database transaction processes. To see a visual representation of Oracle Forms processes showing where each trigger fires, refer to the flowchart for the process named in the "Fires In" section for each trigger. All the flowcharts are in the Oracle Forms Reference Manual, Vol. 2, Chapter 8, "Processing Flow Charts".

1.2 SQL Statements in Trigger Text

The trigger descriptions in this chapter include a section called "Legal Commands." This section lists the types of statements that are valid in the indicated trigger type, including:

• restricted built-in subprograms

• unrestricted built-in subprograms

• SELECT statements

• Data Manipulation Language (DML) statements

Restricted built-in subprograms initiate navigation. They include built-ins that move the input focus from one item to another, such as NEXT_ITEM , and those that involve database transactions, such as CREATE_RECORD.

Restricted built-ins are illegal in triggers that fire in response to navigation, such as Pre- and Post- navigational triggers. Each built-in description includes a "Built-in Type" section that indicates whether the built-in is restricted or unrestricted. For more information, refer to the Oracle Forms Developers Guide, Chapter 7, "Writing Event Triggers."

While you can write a trigger that uses any DML statement, Oracle Corporation advises that you follow the recommendations that are stated for each trigger type. Using DML statements in certain triggers can desynchronize the state of records in Oracle Forms and rows in the database, and can cause unexpected results.

1.3 Trigger Tables

The following cross references are included to help you locate the triggers you need in each category.

1.3.1 Block Processing Triggers

1.3.1.1 When-Clear-Block

Fires just before Oracle Forms clears the data from the current block. Note that the When-Clear-Block trigger does not fire when Oracle Forms clears the current block during the CLEAR_FORM event.

1.3.1.2 When-Create-Record

Fires whenever Oracle Forms creates a new record. For example, when the operator presses the [Insert] key, or navigates to the last record in a set while scrolling down, Oracle Forms fires this trigger.

1.3.1.3 When-Database-Record

Fires when Oracle Forms first marks a record as an insert or an update. That is, the trigger fires as soon as Oracle Forms determines through validation that the record should be processed by the next post or commit as an insert or update. This generally occurs only when the operator modifies the first item in a record, and after the operator attempts to navigate out of the item.

1.3.1.4 When-Remove-Record

Fires whenever the operator or the application clears or deletes a record.

1.3.2 Interface Event Triggers

1.3.2.1 When-Button-Pressed

Fires when an operator selects a button, either by way of a key, or by clicking with a mouse.

1.3.2.2 When-Checkbox-Changed

Fires whenever an operator changes the state of a check box, either by clicking with the mouse, or through keyboard interaction.

1.3.2.3 When-Custom-Item-Event

Fires whenever a VBX control sends an event to Oracle Forms.

1.3.2.4 When-Image-Activated

Fires when an operator double-clicks on an image item with the mouse.

Note that When_Image_Pressed also fires on a double-click.

1.3.2.5 When-Image-Pressed

Fires when an operator uses the mouse to:

• single-click on an image item

• double-click on an image item (note that When_Image_Activated also fires on a double-click)

1.3.2.6 When-List-Changed

Fires when an operator selects a different element in a list item or de-selects the currently selected element. In addition, if a When-List-Changed trigger is attached to a combo box style list item, it fires each time the operator enters or modifies entered text.

1.3.2.7 When-Mouse-Click

Fires after the operator clicks the mouse if one of the following events occurs:

• if attached to the form, when the mouse is clicked within any canvas-view or item in the form

• if attached to a block, when the mouse is clicked within any item in the block

• if attached to an item, when the mouse is clicked within the item

Three events must occur before a When-Mouse-Click trigger will fire:

• Mouse down

• Mouse up

• Mouse click

Any trigger that is associated with these events will fire before the When-Mouse-Click trigger fires.

1.3.2.8 When-Mouse-DoubleClick

Fires after the operator double-clicks the mouse if one of the following events occurs:

• if attached to the form, when the mouse is double-clicked within any canvas-view or item in the form

• if attached to a block, when the mouse is double-clicked within any item in the block

• if attached to an item, when the mouse is double-clicked within the item

Six events must occur before a When-Mouse-DoubleClick trigger will fire:

• Mouse down

• Mouse up

• Mouse click

• Mouse down

• Mouse up

• Mouse double-click

Any trigger that is associated with these events will fire before the When-Mouse-DoubleClick trigger fires.

1.3.2.9 When-Mouse-Down

Fires after the operator presses down the mouse button if one of the following events occurs:

• if attached to the form, when the mouse is pressed down within any canvas-view or item in the form

• if attached to a block, when the mouse is pressed down within any item in the block

• if attached to an item, when the mouse is pressed within the item

Note: The mouse down event is always followed by a mouse up event.

1.3.2.10 When-Mouse-Enter

Fires when the mouse enters an item or canvas-view if one of the following events occurs:

• if attached to the form, when the mouse enters any canvas-view or item in the form

• if attached to a block, when the mouse enters any item in the block

• if attached to an item, when the mouse enters the item

1.3.2.11 When-Mouse-Leave

Fires after the mouse leaves an item or canvas-view if one of the following events occurs:

• if attached to the form, when the mouse leaves any canvas-view or item in the form

• if attached to a block, when the mouse leaves any item in the block

• if attached to an item, when the mouse leaves the item

1.3.2.12 When-Mouse-Move

Fires each time the mouse moves if one of the following events occurs:

• if attached to the form, when the mouse moves within any canvas-view or item in the form

• if attached to a block, when the mouse moves within any item in the block

• if attached to an item, when the mouse moves within the item When-Mouse-Up

1.3.2.13 When-Mouse-Up

Fires each time the operator presses down and releases the mouse button if one of the following events occurs:

• if attached to the form, when the mouse up event is received within any canvas-view or item in a form

• if attached to a block, when the mouse up event is received within any item in a block

• if attached to an item, when the mouse up event is received within an item

Two events must occur before a When-Mouse-Up trigger will fire:

• Mouse down

• Mouse up

1.3.2.14 When-Radio-Changed

Fires when an operator selects a different radio button in a radio group, or de-selects the currently selected radio button, either by clicking with the mouse, or by way of keyboard selection commands.

1.3.2.15 When-Timer-Expired

Fires when a timer expires.

Note: Timers are created programmatically by calling the CREATE_TIMER built-in procedure.

1.3.2.16 When-Window-Activated

Fires when a window is made the active window. This occurs at form startup and whenever a different window is given focus. Note that on some window managers, a window can be activated by, say, clicking on its title bar. This operation is independent of navigation to an item in the window. Thus, navigating to an item in a different window always activates that window, but window activation can also occur independently of navigation.

1.3.2.17 When-Window-Closed

Fires when an operator closes a window using a window-manager specific Close command.

1.3.2.18 When-Window-Deactivated

Fires when an operator deactivates a window by setting the input focus to another window.

1.3.2.19 When-Window-Resized

Fires when a window is resized, either by the operator or programmatically through a call to RESIZE_WINDOW or SET_WINDOW_PROPERTY. (Even if the window is not currently displayed, resizing the window programmatically fires the When-Window-Resized trigger.) This trigger also fires at form startup, when the root window is first drawn. It does not fire when a window is iconified.

1.3.3 Key Triggers

1.3.3.1 Function Key

Function key triggers are associated with individual Runform function keys. A function key trigger fires only when an operator presses the associated function key. The actions you define in a function key trigger replace the default action that the function key would normally perform.

The following paragraph shows all function key triggers and the corresponding Runform function keys : Key-CLRBLK [Clear Block], Key-CLRFRM [Clear Form], Key-CLRREC [Clear Record], Key-COMMIT [Accept], Key-CQUERY [Count Query Hits], Key-CREREC [Insert Record], Key-DELREC [Delete Record], Key-DOWN [Down], Key-DUP-ITEM [Duplicate Item], Key-DUPREC [Duplicate Record], Key-EDIT [Edit], Key-ENTQRY [Enter Query], Key-EXEQRY [Execute Query], Key-EXIT [Exit], Key-HELP [Help], Key-LISTVAL [List of Values], Key-MENU [Block Menu], Key-NXTBLK [Next Block], Key-NXT-ITEM [Next Item], Key-NXTKEY [Next Primary Key], Key-NXTREC [Next Record], Key-NXTSET [Next Set of Records], Key-PRINT [Print], Key-PRVBLK [Previous Block], Key-PRV-ITEM [Previous Item], Key-PRVREC [Previous Record], Key-SCRDOWN [Scroll Down], Key-SCRUP [Scroll Up], Key-UP [Up], Key-UPDREC (Equivalent to Record, Lock command on the default menu).

Note that you cannot redefine all Runform function keys with function key triggers. Specifically, you cannot ever redefine the following static function keys because they are often performed by the terminal or user interface management system and not by Oracle Forms.

[Clear Item], [Copy],

[Cut], [Delete Character],

[Delete Line], [Display Error],

[End of Line], [First Line],

[Insert Line], [Last Line],

[Left], [Paste],

[Refresh], [Right],

[Scroll Left], [Scroll Right],

[Search], [Select],

[Show Keys], [Toggle Insert/Replace],

[Transmit].

The default functionality performed by the following keys is not allowed in Enter Query mode:

[Clear Block], [Clear Form],

[Clear Record], [Accept],

[Insert Record], [Delete Record],

[Down], [Duplicate Item],

[Duplicate Record], [Block Menu],

[Next Block], [Next Primary Key],

[Next Record], [Next Set of Records],

[Previous Block], [Previous Record],

[Up], [Lock Record].

1.3.3.2 Key-Fn

A Key-Fn trigger fires when an operator presses the associated key. You can attach Key-Fn triggers to 10 keys or key sequences that normally do not perform any Oracle Forms operations. These keys are referred to as Key-F0 through Key-F9. Before you can attach key triggers to these keys, you or the DBA must use Oracle Terminal to map the keys to the appropriate functions.

1.3.3.3 Key-Others

A Key-Others trigger fires when an operator presses the associated key.

A Key-Others trigger is associated with all keys that can have key triggers associated with them but are not currently defined by function key triggers (at any level).

A Key-Others trigger overrides the default behavior of a Runform function key (unless one of the restrictions apply). When this occurs, however, Oracle Forms still displays the function key's default entry in the Show Keys screen.

1.3.4 Master-Detail Triggers

1.3.4.1 On-Check-Delete-Master

Oracle Forms creates this trigger automatically when you define a master-detail relation and set the Master Deletes property to Non-Isolated. It fires when there is an attempt to delete a record in the master block of a master-detail relation.

1.3.4.2 On-Clear-Details

Fires when a coordination-causing event occurs in a block that is a master block in a master-detail relation. A coordination-causing event is any event that makes a different record the current record in the master block.

1.3.4.3 On-Populate-Details

Oracle Forms creates this trigger automatically when you define a master-detail relation. It fires when Oracle Forms would normally need to populate the detail block in a master-detail relation.

1.3.5 Message-Handling Triggers

1.3.5.1 On-Error

An On-Error trigger fires whenever Oracle Forms would normally cause an error message to display.

1.3.5.2 On-Message

Fires whenever Oracle Forms would normally cause a message to display.

1.3.6 Navigational Triggers

1.3.6.1 Post-Block

Fires during the Leave the Block process.

1.3.6.2 Post-Form

Fires during the Leave the Form process, when a form is exited.

1.3.6.3 Post-Record

Fires during the Leave the Record process. Specifically, the Post-Record trigger fires whenever the operator or the application moves the input focus from one record to another. The Leave the Record process can occur as a result of numerous operations, including INSERT_RECORD, DELETE_RECORD, NEXT_RECORD, CREATE_RECORD, NEXT_BLOCK, PREVIOUS_BLOCK, etc.

1.3.6.4 Post-Text-Item

Fires during the Leave the Item process for a text item. Specifically, this trigger fires when the input focus moves from a text item to any other item.

1.3.6.5 Pre-Block

Fires during the Enter the Block process, during navigation from one block to another.

1.3.6.6 Pre-Form

Fires during the Enter the Form event, at form startup.

1.3.6.7 Pre-Record

Fires during the Enter the Record process, during navigation to a different record.

1.3.6.8 Pre-Text-Item

Fires during the Enter the Item process, during navigation from an item to a text item.

1.3.6.9 When-Form-Navigate

Fires whenever any peer form navigation takes place.

1.3.6.10 When-New-Block-Instance

Fires when the input focus moves to an item in a block that is different than the block that previously had input focus. Specifically, it fires after navigation to an item, when Oracle Forms is ready to accept input in a block that is different than the block that previously had input focus.

1.3.6.11 When-New-Form-Instance

At form start-up, Oracle Forms navigates to the first navigable item in the first navigable block. A When-New-Form-Instance trigger fires after the successful completion of any navigational triggers that fire during the initial navigation sequence. This trigger does not fire when control returns to a calling form from a called form. In a multiple-form application, this trigger does not fire when focus changes from one form to another.

1.3.6.12 When-New-Item-Instance

Fires when the input focus moves to an item. Specifically, it fires after navigation to an item, when Oracle Forms is ready to accept input in an item that is different than the item that previously had input focus.

1.3.6.13 When-New-Record-Instance

Fires when the input focus moves to an item in a record that is different than the record that previously had input focus. Specifically, it fires after navigation to an item in a record, when Oracle Forms is ready to accept input in a record that is different than the record that previously had input focus.

Fires whenever Oracle Forms instantiates a new record.

1.3.7 Query-Time Triggers

1.3.7.1 Post-Query

When a query is open in the block, the Post-Query trigger fires each time Oracle Forms fetches a record into a block. The trigger fires once for each record placed on the block's list of records.

1.3.7.2 Pre-Query

Fires during Execute Query or Count Query processing, just before Oracle Forms constructs and issues the SELECT statement to identify rows that match the query criteria.

1.3.8 Transactional Triggers

1.3.8.1 On-Check-Unique

During a commit operation, the On-Check-Unique trigger fires when Oracle Forms normally checks that primary key values are unique before inserting or updating a record in a base table. It fires once for each record that has been inserted or updated.

1.3.8.2 On-Close

Fires when an operator or the application causes a query to close. By default, Oracle Forms closes a query when all of the records identified by the query criteria have been fetched, or when the operator or the application aborts the query. The On-Close trigger augments the normal Oracle Forms "close cursor" phase of

1.3.8.3 On-Column-Security

Fires when Oracle Forms would normally enforce column-level security for each block that has the Column Security block property set On.

1.3.8.4 On-Commit

Fires whenever Oracle Forms would normally issue a database commit statement to finalize a transaction. By default, this operation occurs after all records that have been marked as updates, inserts, and deletes have been posted to the database.

1.3.8.5 On-Count

Fires when Oracle Forms would normally perform default Count Query processing to determine the number of rows in the database that match the current query criteria. When the On-Count trigger completes execution, Oracle Forms issues the standard query hits message: FRM-40355: Query will retrieve records.

1.3.8.6 On-Delete

Fires during the Post and Commit Transactions process. Specifically, it fires after the Pre-Delete trigger fires and before the Post-Delete trigger fires, replacing the actual database delete of a given row. The trigger fires once for each row that is marked for deletion from the database.

1.3.8.7 On-Fetch

When a query is first opened, fires immediately after the On-Select trigger fires, when the first records are fetched into the block. While the query remains open, fires again each time a set of rows must be fetched into the block.

1.3.8.8 On-Insert

Fires during the Post and Commit Transactions process. Specifically, it fires after the Pre-Insert trigger fires and before the Post-Insert trigger fires, when Oracle Forms would normally insert a record in the database. It fires once for each row that is marked for insertion into the database.

1.3.8.9 On-Lock

Fires whenever Oracle Forms would normally attempt to lock a row, such as when an operator presses a key to modify data in an item. The trigger fires between the keypress and the display of the modified data.

1.3.8.10 On-Logon

Fires once per logon when Oracle Forms normally initiates the logon sequence.

1.3.8.11 On-Logout

Fires when Oracle Forms normally initiates a logout procedure.

1.3.8.12 On-Rollback

Fires when Oracle Forms would normally issue a ROLLBACK statement, to roll back a transaction to the last savepoint that was issued.

1.3.8.13 On-Savepoint

Fires when Oracle Forms would normally issue a Savepoint statement. By default, Oracle Forms issues savepoints at form startup, and at the start of each Post and Commit Transaction process.

1.3.8.14 On-Select

Fires when Oracle Forms would normally execute the selection phase of a query, to identify the records in the database that match the current query criteria.

1.3.8.15 On-Sequence-Number

Fires when Oracle Forms would normally perform the default processing for generating sequence numbers for default item values.

1.3.8.16 On-Update

Fires during the Post and Commit Transactions process. Specifically, it fires after the Pre-Update trigger fires and before the Post-Update trigger fires, when Oracle Forms would normally update a record in the database. It fires once for each row that is marked for update in the form.

1.3.8.17 Post-Change

Fires when any of the following conditions exist:

• The Validate the Item process determines that an item is marked as Changed and is not NULL.

• An operator returns a value into an item by making a selection from a list of values, and the item is not NULL.

• Oracle Forms fetches a non-NULL value into an item. In this case, the When-Validate-Item trigger does not fire. If you want to circumvent this situation and effectively get rid of the Post-Change trigger, you must include a Post-Query trigger in addition to your When-Validate-Item trigger. See "Usage Notes" below.

1.3.8.18 Post-Database-Commit

Fires once during the Post and Commit Transactions process, after the database commit occurs. Note that the Post-Forms-Commit trigger fires after inserts, updates, and deletes have been posted to the database, but before the transaction has been finalized by issuing the Commit. The Post-Database-Commit Trigger fires after Oracle Forms issues the Commit to finalize the transaction.

1.3.8.19 Post-Delete

Fires during the Post and Commit Transactions process, after a row is deleted. It fires once for each row that is deleted from the database during the commit process.

1.3.8.20 Post-Forms-Commit

Fires once during the Post and Commit Transactions process. If there are records in the form that have been marked as inserts, updates, or deletes, the Post-Forms-Commit trigger fires after these changes have been written to the database but before Oracle Forms issues the database Commit to finalize the transaction.

If the operator or the application initiates a Commit when there are no records in the form have been marked as inserts, updates, or deletes, Oracle Forms fires the Post-Forms-Commit trigger immediately, without posting changes to the database.

1.3.8.21 Post-Insert

Fires during the Post and Commit Transactions process, just after a record is inserted. It fires once for each record that is inserted into the database during the commit process.

1.3.8.22 Post-Logon

Fires after either of the following events:

• The successful completion of Oracle Forms default logon processing.

• The successful execution of the On-Logon trigger.

1.3.8.23 Post-Logout

Fires after either of the following events:

• Oracle Forms successfully logs out of ORACLE.

• The successful execution of the On-Logout trigger.

1.3.8.24 Post-Select

The Post-Select trigger fires after the default selection phase of query processing, or after the successful execution of the On-Select trigger. It fires before any records are actually retrieved through fetch processing.

1.3.8.25 Post-Update

Fires during the Post and Commit Transactions process, after a row is updated. It fires once for each row that is updated in the database during the commit process.

1.3.8.26 Pre-Commit

Fires once during the Post and Commit Transactions process, before Oracle Forms processes any records to change. Specifically, it fires after Oracle Forms determines that there are inserts, updates, or deletes in the form to post or commit. The trigger does not fire when there is an attempt to commit, but validation determines that there are no changed records in the form.

1.3.8.27 Pre-Delete

Fires during the Post and Commit Transactions process, before a row is deleted. It fires once for each record that is marked for delete. Note: Oracle Forms creates a Pre-Delete trigger automatically for any master-detail relation that has the Master Deletes property set to Cascading.

Pre-Insert Fires during the Post and Commit Transactions process, before a row is inserted. It fires once for each record that is marked for insert.

1.3.8.28 Pre-Logon

Fires just before Oracle Forms initiates a logon procedure to the data source.

1.3.8.29 Pre-Logout

Fires once before Oracle Forms initiates a logout procedure.

1.3.8.30 Pre-Select

Fires during Execute Query and Count Query processing, after Oracle Forms constructs the SELECT statement to be issued, but before the statement is actually issued. Note that the SELECT statement can be examined in a Pre-Select trigger by reading the value of the system variable SYSTEM.LAST_QUERY.

1.3.8.31 Pre-Update

Fires during the Post and Commit Transactions process, before a row is updated. It fires once for each record that is marked for update.

1.3.9 Validation Triggers

1.3.9.1 When-Validate-Item

Fires during the Validate the Item process. Specifically, it fires as the last part of item validation for items with the New or Changed validation status.

1.3.9.2 When-Validate-Record

Fires during the Validate the Record process. Specifically, it fires as the last part of record validation for records with the New or Changed validation status.

1.3.9.3 User-Named Trigger

A user-named trigger is a trigger that you define yourself in a form, and then call explicitly from other triggers or user-named subprograms. Each user-named trigger defined at the same definition level must have a unique name.

To execute a user-named trigger, you must call the EXECUTE_TRIGGER built-in procedure, as shown here:

Execute_Trigger('my_user_named_trigger');

Note: You can write user-named PL/SQL subprograms to perform almost any task for which you might use a user-named trigger.