ORACLE PROJECTS: Oracle Forms Notes

Oracle Forms

Form:

A form is a collection of Objects and code.

Trigger:

A trigger is a set of PL/SQL code that fires when an event occurs.

Alerts:

An Alert is a model window used to display a message.

Blocks:

Blocks are logical containers, which groups items for storing, displaying and manipulating records.

Types of blocks

Base Block : A Base Block is associated with a database Table/View
Control Block : A control block is not associated with a database table or views.

Canvas:

Canvases are background objects where items and objects are place. Each canvas is displayed in a window.
Types of Canvases

Content
Stacked
Tab
Horizontal Toolbar
Vertical Toolbar

Content Canvas:

The most common canvas type is the content canvas (the default type). A content canvas is the "base" view that occupies the entire content pane of the window in which it is displayed. You must define at least one content canvas for each window you create.

Stacked Canvas:

A stacked canvas is displayed atop�or stacked on�the content canvas assigned to the current window. Stacked canvases obscure some part of the underlying content canvas, and often are shown and hidden programmatically. You can display more than one stacked canvas in a window at the same time.

Tab Canvas:

A tab canvas�made up of one or more tab pages�allows you to group and display a large amount of related information on a single dynamic Form Builder canvas object. Like stacked canvases, tab canvases are displayed on top of a content canvas, partly obscuring it. Tab pages (that collectively comprise the tab canvas) each display a subset of the information displayed on the entire tab canvas.

Toolbar Canvas:

A toolbar canvas often is used to create toolbars for individual windows. You can create two types of toolbar canvases: horizontal or vertical. Horizontal toolbar canvases are displayed at the top of a window, just under its menu bar, while vertical toolbars are displayed along the far left edge of a window.

Window:

A window is an empty frame on which a canvas is place.

LOV:

LOV is a scrollable pop up window, which provides a list of values. LOVs are derived from Record Groups.

Record Group:

A record Group is a data structure that is internally created by Oracle Forms. It is similar to a database table because of row/column framework.

Visual Attributes:

This Object consists of font, color and pattern settings, which can be used, in Form and Menu Objects.

Property Classes:

Property Classes contains a list of properties and their settings.

Program Units:

Program Units are user-named sub programs (Procedures & Functions) that are created for a module (Form, Menu or Library). They are reusable.

Built-in Packages:

Grouping of PL/SQL functions available in Oracle Forms.

Libraries:

Grouping of subprograms that include user-named procedures, functions and packages. They help in storing the client-side program units share them across multiple applications.

Object Groups:

Object Group is a container for a group of Objects.

Master � Detailed Relationships:

Non-Isolated	This is the default setting. It presents the deletion of a Master record when an associated Detail record exists in the database.
Isolated	It allows deletion of Master record without affecting associated Detail records in the database.
Cascading	It allows Master record to be deleted and automatically deletes any associated detail records.

Relation Properties:

Co-Ordination Property: (Default: Non-Isolated)

Deffered	Auto Query	Result
N	N/Y	Detail records populate automatically whenever we query the master record
Y	N	Explicitly execute the function �Execute Query� to populate detail block
Y	Y	Whenever Control focus on details block records will populate

Delete Record Behavior (Default: Non-Isolated)

	Triggers Created	Behavior
Cascading	Form Level: On_Clear_Details Block Level: Pre-Delete On-Populate-Details	Allows the master record to be deleted and automatically deletes any associated detail records in the detail block's base table at commit time
Isolated	Form Level: On Clear Details Block Level: On-Populate-Details	Allows the master record to be deleted and does not affect associated detail records in the database
Non-Isolated	Form Level: On Clear Details Block Level: On-Check-Delete-Master On-Populate-Details	Prevents the deletion of a master record when associated detail records exist in the database

List Item:

A list item is a list of text elements that can be displayed as a poplist, Tlist, or combo box.

Poplist	The poplist style list item appears initially as a single field (similar to a text item field). When the end user selects the list icon, a list of available choices appears.
Tlist	The Tlist style list item appears as a rectangular box which displays a fixed number of values. When the Tlist contains values that cannot be displayed (due to the displayable area of the item), a vertical scroll bar appears, allowing the end user to view and select undisplayed values.
Combo Box	The combo box style list item combines the features found in poplists and text items. It displays fixed values and can accept a user-entered value.

Parameters:

The parameter Object is used for defining and setting input values required by Form during start up. There are two types of parameters.

Text Parameter: Text Parameters are used to pass values between Forms.
Data Parameter: Data Parameters are used to pass values between Forms and other Oracle related products like Oracle Reports, Oracle Graphics.

Parameters are passed to called forms by means of a parameter list. A parameter list is a named programmatic construct that is simply a list of parameter names (called keys) and their values.You can pass parameter values to forms invoked by the built-in subprograms CALL_FORM, OPEN_FORM, and NEW_FORM. In addition, you can pass parameter values to other Oracle tools with the RUN_PRODUCT procedure.

A parameter you include in a parameter list can be either a text parameter or a data parameter. The parameter type determines how its value is interpreted.

Text Parameters	The value of a text parameter being passed to a called product is a CHAR string that can represent the following: a user-defined form parameter defined in a form invoked by the CALL_FORM, OPEN_FORM, or NEW_FORM built-in subprograms a command line or user-defined parameter for a product invoked with the RUN_PRODUCT built-in subprogram
Data Parameters	The value of a data parameter being passed to a called product is always the name of a record group defined in the current form. (A record group is a data structure that stores records derived from a query or through programmatic assignment.) Data parameters are used to pass data to products invoked with the RUN_PRODUCT built-in subprogram. You cannot pass data parameters to forms.

PROCEDURE RUN_PRODUCT (product NUMBER, module VARCHAR2, commmode NUMBER, execmode NUMBER, location NUMBER, paramlist_id VARCHAR2, display VARCHAR2);

Commmode:

SYNCHRONOUS	specifies that control returns to Form Builder only after the called product has been exited. The end user cannot work in the form while the called product is running.
ASYNCHRONOUS	specifies that control returns to the calling application immediately, even if the called application has not completed its display.

CALL_FORM:

Runs an indicated form while keeping the parent form active. Form Builder runs the called form with the same Runform preferences as the parent form. When the called form is exited Form Builder processing resumes in the calling form at the point from which you initiated the call to CALL_FORM.

NEW_FORM:

Exits the current form and enters the indicated form. The calling form is terminated as the parent form. If the calling form had been called by a higher form, Form Builder keeps the higher call active and treats it as a call to the new form. Form Builder releases memory (such as database cursors) that the terminated form was using.

OPEN_FORM:

Opens the indicated form. Use OPEN_FORM to create multiple-form applications, that is, applications that open more than one form at the same time.

EXIT_FORM:

Provides a means to exit a form, confirming commits and specifying rollback action

In most contexts, EXIT_FORM navigates �outside� the form. If there are changes in the current form that have not been posted or committed, Form Builder prompts the operator to commit before continuing EXIT_FORM processing.
If the operator is in Enter Query mode, EXIT_FORM navigates out of Enter Query mode, not out of the form.
During a CALL_INPUT, EXIT_FORM terminates the CALL_INPUT function.

CLOSE_FORM:

Opens the indicated form. Use OPEN_FORM to create multiple-form applications, that is, applications that open more than one form at the same time.

CLOSE_FORM Restrictions:

You cannot close a form that is currently disabled as a result of having issued CALL_FORM to invoke a modal called form.
You cannot close a form that has called you. For example, if Form_A calls Form_B, then Form_B cannot close Form_A.

User-Named Trigger:

A user-named trigger is a trigger defined in a form by the developer. User-Named triggers do not automatically fire in response to a Form Builder event, and must be called 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');

Triggers or Event Handlers

Active X triggers:

On-Dispatch-Event

Block processing triggers:

When-Clear-Block

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

When-Create-Record

Fires when Form Builder 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, Form Builder fires this trigger.

When-Database-Record

Fires when Form Builder first marks a record as an insert or an update. That is, the trigger fires as soon as Form Builder 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.

When-Remove-Record

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

Interface Event triggers:

When-Button-Pressed
When-Checkbox-Changed
When-Custom-Item-Event
When-Image-Activated
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-Radio-Changed
When-Timer-Expired
When-Window-Activated
When-Window-Closed
When-Window-Deactivated
When-Window-Resized

Key triggers:

Key-Fn
Key-Others

A Key-Others trigger fires when an operator presses the associated key.
A Key-Others trigger overrides the default behavior of a Runform function key

Master-Detail triggers:

On-Check-Delete-Master

Form Builder creates this trigger automatically when you define a master/detail relation and set the Delete Record Behavior property to Non-Isolated. It fires when there is an attempt to delete a record in the master block of a master/detail relation.

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.

On-Populate-Details

Form Builder creates this trigger automatically when a Master/Detail relation is defined. It fires when Form Builder would normally need to populate the detail block in a Master/Detail relation.

Message-Handling triggers:

On-Error

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

On-Message

Fires whenever Form Builder would normally cause a message to display and pre-empts the message.

Mouse Event triggers:

When-Custom-Item-Event
When-Mouse-Click
When-Mouse-DoubleClick
When-Mouse-Down
When-Mouse-Enter
When-Mouse-Leave
When-Mouse-Move
When-Mouse-Up

Navigation triggers:

Post-Block
Post-Form
Post-Record
Post-Text-Item
Pre-Block
Pre-Form
Pre-Record
Pre-Text-Item
User-Named
When-New-Block-Instance
When-New-Form-Instance
When-New-Item-Instance
When-New-Record-Instance

On triggers:

On-Check-Delete-Master
On-Check-Unique
On-Clear-Details
On-Close
On-Column-Security
On-Commit
On-Count
On-Delete
On-Dispatch-Event
On-Error
On-Fetch
On-Insert
On-Lock
On-Logon
On-Logout
On-Message
On-Populate-Details
On-Rollback
On-Savepoint
On-Select
On-Sequence-Number
On-Update

Post triggers:

Post-Block
Post-Change
Post-Database-Commit
Post-Delete
Post-Form
Post-Forms-Commit
Post-Insert
Post-Logon
Post-Logout
Post-Query
Post-Record
Post-Select
Post-Text-Item
Post-Update

Pre triggers:

Pre-Block
Pre-Commit
Pre-Delete
Pre-Form
Pre-Insert
Pre-Logon
Pre-Logout
Pre-Popup-Menu
Pre-Query
Pre-Record
Pre-Select
Pre-Text-Item
Pre-Update

Query-Time triggers:

Post-Query
Pre-Query

Stored Procedure triggers:

Delete-Procedure
Insert-Procedure
Lock-Procedure
Query-Procedure
Update-Procedure

Stored Procedure triggers are automatically created by Form Builder when the insert /update/delete data source is a stored procedure. This trigger is called when a insert/update/delete operation is necessary. Think of this as an ON-INSERT trigger/ON-UPDATE trigger/ON-DELETE trigger that is called by the system instead of doing default insert operations.

Transactional triggers:

Pre triggers
Post triggers
On triggers

Validation triggers:

When-Validate-Item
When-Validate-Record

When triggers:

When-Button-Pressed
When-Checkbox-Changed
When-Clear-Block
When-Create-Record
When-Custom-Item-Event
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

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.

Trigger	Typical 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-Commit	Augment 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.

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.

ORACLE PROJECTS

MENUS

Thursday, 17 April 2014

Oracle Forms Notes