Using Form Builder - Object Navigator | Oracle Application Server 10g Web Development (Oracle Press)

The Object Navigator is part of the Forms toolkit. It is displayed automatically when Forms Developer starts and shows all the objects that you create in Forms designer (Figure 3-4).

Figure 3-4: The Forms Builder module

The Object Navigator organizes the modules and objects within the workspace. It consists of a toolbar and hierarchical object management section. Objects are grouped into nodes based on type ( menus , forms, blocks, items, etc.). You can view all the objects in a form by expanding and collapsing the nodes in the form. You can view items in three ways:

Ownership View Grouped by type (see Figure 3-4).
Visual View Objects are shown organized by containers so that canvases are contained in windows , and items are shown in canvases, etc.
PL/SQL Only Only objects with associated PL/SQL code are displayed in either view.

Wizards

While forms can be built manually, Forms provides a number of wizards to assist with development:

Data Block Wizard
Layout Wizard
LOV Wizard

Wizards can speed the development of Forms by providing default behavior and layouts, and all of them are reentrant. In many cases, making changes to the objects by using the wizard is much easier than manually updating each property. Note, however, that rerunning the wizards can overwrite the changes you have made with the defaults from Forms.

Exercise: Building a Simple Form

There are four basic steps to creating a simple form that allows Select, Update, Insert, and Delete on a single table:

Create a new form module in the Object Navigator
Create a block based on a database table
Arrange the items in the block on a canvas
Run the form

Instead of discussing in detail how to create and run a form, let s create a simple form and then discuss the results. This should make it easier to understand how the basic elements function. Just follow along with the steps:

Create a new Form module (highlight the node under forms and click the green plus sign). When you open Forms Builder, you may be offered the option to open an existing form or create a new one, and by default, a new, empty module is created (Figure 3-4).
The Data Block Wizard automates the task of creating blocks and items. It is the fastest way to create a default block and layout, and is the basis for most forms (Figure 3-5). Give focus to the Data Blocks node and press the green + button (create). Select Use Data Block Wizard to continue.

Figure 3-5: The New Data Block dialog box

You can also create data blocks manually by choosing Build New Data Block Manually. This is used to create Control blocks. While it is possible to build a table-based block manually, it is not recommended and can be quite tedious ! It is nearly always easier to start with the wizard-generated block and made adjustments as necessary.

If the Welcome screen is displayed, click OK. Select Table or View as the type of data block and press the Next button (Figure 3-6).

Figure 3-6: The first step of the Data Block Wizard
Click Browse and log in to the database if you are prompted to (Figure 3-7).

Figure 3-7: The second step of the Data Block Wizard
Select the S_DEPT table from the list and click OK (Figure 3-8). This list of values can display those items that belong to your user, or those that belong to another user .

Figure 3-8: The Tables dialog box
The Available columns will display all the columns in the table. Use the arrow buttons to move the columns into the database items region. Only the columns in the database items region will be incorporated into the form. Press Next (Figure 3-9).

Figure 3-9: The Data Block Wizard with the selected table displayed
Enter a name for the data block (Figure 3-10). This name will default to the name of the table or view you are basing the block on. Normally, you will not want to override this name .

Figure 3-10: Entering a name for the data block
When the Congratulations dialog box is displayed, select Create the Data Block, then call the Layout Wizard option and press Finish (Figure 3-11).

Figure 3-11: The final step of the Data Block Wizard
The Layout Wizard will assist in creating a default canvas and window, and arranging the selected items on it (Figure 3-12). Accept the default settings of New Canvas and Content and press Next.

Figure 3-12: The first page of the Layout Wizard
The Available Items region will display the columns that you chose from the previous wizard. Use the arrow buttons to move the columns into the Displayed Items region. Press Next (Figure 3-13).

Figure 3-13: The Layout Wizard with items selected
Change the Prompt value for the columns (Figure 3-14). This page allows you to control the physical display of the items. Do not change anything yet. Press Next.

Figure 3-14: Setting item attributes in the Layout Wizard
Select Tabular and press Next (Figure 3-15).

Figure 3-15: Setting attributes for the frame in the Layout Wizard
Set the Frame Title to Departments and the Records Displayed to 10. Check Display Scrollbar. Press Next.
Press the Finish button. Your Forms toolkit should look something like this (Figure 3-16).

Figure 3-16: Forms Builder after successfully generating the form

Compiling the Form

Make sure to save your work. Note that there is a limitation in the way the web run time reads directory names that include spaces; make sure that you save the form into a directory that can be read.

Note	If you store files in a directory with spaces, you will receive an error when you attempt to run your form.

The Forms compiler is the component used to compile Form source code (.fmb) into executable code (.fmx) that can be run on the Web. This is the deployable version of the form.

Running the Form

Previous versions of Forms supported a client-server implementation, which required that a run-time engine be installed or accessible from each client machine. Forms 10 g no longer supports client-server deployment. All forms are run on the Web via a browser.

One of the major misconceptions about Web Forms in earlier versions was that the form was built and compiled in the Forms Designer, and then run through some sort of converter to generate the Java code that runs the form in the browser. This is not the case.

However, running a form for the first time does require some Java support, in the form of a thin Java applet that handles the display of the Oracle form in the browser. The applet is downloaded and cached on the client machine. The Forms Applet provides the user interface for the form and is responsible for rendering the display. It does not contain any specific application logic (that is, in the form itself). The same applet can be used for any form, regardless of size or complexity. Preferences control how the forms run in the browser.

Using OC4J

Testing the forms locally requires that an OC4J instance is running. In Windows, this can be started from the menu Forms Developer Start OC4J Instance. Once the OC4J instance is running, simply press the Run button in the form. If this is the first time you have run forms from within Forms Builder, you will have to download the Java Applet code. Follow the instructions to perform the default installation of the Applet. After the applet loads, we can test our form displayed in the browser (Figure 3-17).

Figure 3-17: The generated form displayed in a web browser

Note that the pull-down menu and toolbar presented in your form are fully functional. They are default options that are automatically attached to every new form. The form is functional right out of the box. You can query, update, and delete records; scroll through them; and even insert records ”although you will need to be sure to create a unique identifier!

The large window that you see is the Forms MDI window. This is a standard window management technique in which all other windows of the application are contained with the parent window. This is the default management technique for Forms applications. However, a Single Document Interface (SDI) is also available.

In the browser, the Forms MDI window appears within the Java Applet space. By default, this applet space is 650 x 500 pixels, and the MDI window is maximized within it. The default size of the Applet frame can be changed by editing the height and width properties in the following file: $ORACLE_HOME/forms90/formsweb.cfg. This should be set to the normal expected size of the browser window. In most cases, 800 x 600 is the lowest common denominator size and forms should be designed to fit within that window. However, the value can be set higher if each of the users can support the configuration. Do not design at higher resolutions unless you can ensure that all users can view the forms.

Property Palettes

Every item in a form has properties that control its behavior and appearance. Using the Wizard sets these properties to default values, which can then be changed to customize the item. The appearance and behavior of form objects (and even the form itself) can be altered by changing the properties defined for it. Display the property palette for an item by either selecting it from the Tools menu, double-clicking on the object in the Object Navigator (except for canvases, when double-clicking simply displays the canvas), or right-clicking the object and selecting Property Palette from the popup menu.

In many cases, the default value for a property is fine. However, when you change a property, it is displayed with a small green square next to the name.

Basic Interface Items

Items that the user can interact with on the canvas are called interface items. The most common types of interface items are Text Items and Display Items.

Text Items

In the basic form that we created above, the only type of interface item we created was a simple Text Item. These interface items allow the user to interact with the data in the form field. A majority of items in a form are often text items, as these are the primary data entry fields for a form.

Display Items

A Display Item is (as its name suggests) an interface item for display only. They are similar to Text Items, but the user cannot update the data displayed in them. The same effect can be attained by setting enterable, update allowed, and insert allowed properties of a text item to prohibit the user from changing it, although this is not the preferred way of handling displayed data. Display items are not navigable.

Interface Items

A form built with just Text Items and Display Items is functional, but they are not easy for the user to work with. Older applications often required that users memorize or look up complex codes for things, and required developers to write code to handle verification of the data a user would type in. Was that a Y or yes that you need to type in for Preferred Customer? What are the codes for shipping?

Constraints in the database can be used to catch these data entry issues, and hints could be provided, but there is a much better approach. Using Check Boxes, Radio Groups, and List Boxes can control the data entry for specific fields.

All of these interface items are used to give the user a choice of multiple values that map back to a single value in the database. No matter how many Radio Buttons you can choose from, or how many items are in a list, only one value is stored in the database. One of the other advantages of using these interface items is that the displayed value is not necessarily the value that is stored in the database. A Check Box may be labeled Require Phone Number? but the value stored is either a Y or N.

These alternate interface items can be created by simply drawing the appropriate object type in the Layout Editor (from the object buttons on the left), or by selecting the item and changing its item type property in the property palette.

Check Boxes

Check Boxes are used when there are two choices for a field: on or off. A Check Box should have a clear binary choice between opposite values “ YES/NO, ON/OFF, PREFFERED/NOT PREFERRED. The checked and unchecked values should be intuitive. You would probably not use a Check Box for MALE/FEMALE (unless you were tracking Dennis Rodman).

Most Check Boxes are backed up by a not null constraint and a check constraint in the database. Check Boxes have several properties that control their behavior:

Value when checked The value that will be inserted into the database when the Check Box is checked.
Value when unchecked The value that will be inserted into the database when the Check Box is not checked.
Check Box Mapping of Other Values This property controls how records queried from the database will be handled if the value in the database is not one of the two values allowed by the Check Box. The erroneous value may be shown as checked or unchecked, or it may be NOT ALLOWED, which will ignore the record and not display it in the form (which is often confusing to users, since the data can be seen in other tools).

For example, if the Check Box is set up to allow the values Y and N, but somehow an M is present in the data, forms can either pretend the M is a Y or N, or discard the record entirely. Note that displaying the bad value as one of the allowed values does not automatically change the value to the allowed value. It remains an M in the database unless it is explicitly changed.

Tip	Do not use a series of Check Boxes that behaves like a radio group (i.e., writing code to allow the user to check only one of the many checkboxes and uncheck the rest). Use a radio group instead.

Radio Group

For those of us old enough to remember old car radios, the similarity of this widget to the little push-buttons to change the stations is obvious. Only one item can be selected at a time.

A Radio Group is used when there are two to six values to choose from, and the user must select one value. Like the Check Box, Radio Groups are usually backed up by not null constraints and either a check constraint or foreign key relationship in the database.

The Radio Group is the container, which is bound to the database item, and contains radio buttons. The group itself has no physical representation on the canvas; only the buttons are shown. The buttons have associated values that are inserted into the database.

The Radio Group has a Mapping of Other Values property (like Check Boxes and List Boxes). Leaving the property NULL disregards the invalid value. Otherwise, the value can be displayed as one of the valid radio choices.

List Boxes

List Boxes, or drop-down boxes, display a list of valid values to the user. One value can be selected. Each List Box must have an associated list of values (which can be hard-coded into the list box item, or dynamically attached from a Record Group).

The following properties control List Boxes:

Elements in list The display value and database value pairs for the list.
Mapping of Other Values Controls how records queried in the database will be handled if the value in the list column does not match the value of an item currently in the list. Leaving this property NULL means disregarding the record and not displaying it on screen. Setting the value of one of the items in the list will display the record as though it had that value. Again, it does not change the bad value to an accepted one, it only displays it.

List Boxes come in several flavors, which behave slightly differently.

Pop list The standard List Box, which initially displays a single value that can be expanded to view the rest of the list. This is the most common type of list box.
T-List This List Box is less common, but can be used when there are only a few items to display. It takes of a lot of screen real estate, and because of the multiline display users often attempt to select multiple items. Even though multiple lines are displayed, the user can still only choose one value.
Combo Box Combo Boxes are rarer yet. Initially, they behave just like a Pop list. However, a Combo Box allows the user to type in a value that is not in the list and have that value saved to the database. However, if the list is hardcoded (in the Element in List property), the new value will not display in the list the next time it is used. In order to have a Combo Box display user-entered data immediately, it must dynamically build the list-of-values (LOVs).

Buttons

After text items, Buttons are the most common interface item in forms. Buttons are a specific widget designed to mimic an actual push button, and perform an action when they are pressed. Buttons are not bound to database items.

Buttons have the following properties:

Label The wording that appears on the button. Buttons can also be iconic.
Default button The button indicating it s the default button for the block. It will be displayed with default highlighting. It is important to remember that the default button for a screen should never be a destructive button. Users have a tendency to press Return blindly and the action performed by the button should not be one that makes permanent changes to data or begins processing. For example, do not make the default button OK on a confirmation dialog window, since this may mean that the user will inadvertently perform that complete delete because he did not read the dialog message.
Mouse navigation This property indicates if the cursor should move focus to the button when it is pressed, or whether the cursor should remain where it is, and no navigation should occur.

Record Groups

Record Groups are internal Forms structures that behave like tables in memory. They have no visual representation, and by themselves , have no values. However, they are used to drive other interface items such as LOVs and List Boxes.

Record Groups can be based on a list of static values (although this is not common) or on queries. The query can be as simple or complex as necessary to return the values you need. Record Groups can reference forms objects, system objects, or other variables .

List of Values

A list-of-values (LOVs) displays a pop-up listing of available values for a form field. It is based on a record group. The LOV Wizard can easily create a list of values (and the associated Record Group).

The Record Group behind an LOV can have as many columns as you want to display, for informational purposes. Each column in the LOV can be linked to a displayed field so that when the LOV item is selected, it can populate a number of fields on screen. Each column in the LOV can return to only one field in the form.

When one of the values of the LOV is returned to the form, you have the option to attach the LOV to one of the fields so the users can invoke the list to select a value. An LOV is assigned to a text item in the form by setting the following properties:

List of values Which LOV to associate with this item.
List X Position/List Y Position Specific location to display the LOV.
Validate from List Indicates that the LOV should be used to determine that the data entered into the field is valid. When data is typed into the field, the LOV is consulted to determine if the value entered is included in the LOV. For this property to work, the first column of the LOV must be the column that is bound to the form item.

Layout Editor

Each of the interface items listed above has a property palette, which includes information about location, size, color , and font. Each item can be customized by changing the value in the property palette, but it is much easier using the Layout Editor (Figure 3-18).

Figure 3-18: The Layout Editor

The Layout Editor is a graphical tool for working with the visual elements of a form. The Layout Editor, Property Palette, and Object Navigator are linked together ”if you make a change in one, the others are automatically synchronized.

Layout Editor Buttons

Using the buttons and Layout Menu, you can design the look and feel of the form easily. See Figure 3-19 for the layout buttons in the Layout Editor.

Figure 3-19: Buttons in the Layout Editor

To find out what a specific button does, simply point to it with the cursor ”a Tooltip will display describing the button s function. The toolbar on the left-hand side of the Layout Editor includes these buttons:

Use these buttons to select, rotate, zoom, or reshape items
Use these buttons to create boilerplate graphics objects such as boxes or lines. Boilerplate items are read-only and the user cannot interact with them.
Use these buttons to create boilerplate text. Remember that item prompts are now properties that are associated with the item itself. Do not use boilerplate for item prompts.
Use this button to create a new frame object that can be used for auto-layout.
Use these buttons to create interface items such as buttons, check boxes, radio buttons, text items, images, charts , JavaBean areas, display items, list items, and hierarchical tree items. Note that you can create these items in the layout editor and they will be created in the data block that has current focus, or the first block in the form if none of them have focus.
Use this button to create a tab canvas.
Use this button to create a stacked canvas on top of this one.
Use these buttons to control the background/fill color, line color, and text color.

Across the top of the Layout Editor are additional layout buttons:

Use these drop-down menus to set the font and size for items.
Use these buttons to set the font attributes (bold, italic, underline) for items, prompts, and boilerplate.
Use these buttons to zoom in and out.
Use these buttons to align multiple objects, horizontally and vertically. You can also align objects using the menu selection Layout Align Components . Note that aligning left will align the object with the one that is farthest left; aligning top will align the objects with the object that is highest, etc.
Use these buttons to change the layout order of the items by moving items to the front or moving them behind other objects.

Adding Functionality

So far, forms are collections of objects displayed on a canvas. Users can invoke the built-in functionality for DML actions (Select, Insert, Update, Delete). Our forms might look nice, but they don t do much yet.

Functionality is added to the Form using interface items and adding PL/SQL code behind the scenes to make the form work. Oracle Forms 10 g is event driven; that is, code is run in response to specific actions by the user or generated by the form. Events are predefined actions that occur within a form.

Events

Users generate events by moving the mouse, clicking a mouse button, tabbing from one item to another, changing the data in an item, or other interaction with the GUI. The form itself generates events for nearly every action that it takes. Opening a form, opening or closing a window, moving from one item to another or one block to another, coordinating master-detail relationships are all examples of forms-generated events.

Every predefined event in the form can be trapped by a corresponding trigger. Triggers allow us to add functionality to the form to augment or replace the default behavior. Each predefined event has a specific trigger associated with it. For example, when a button is pressed, it is captured by a when-button-pressed trigger. There are user-defined triggers, but they are of minimal use and are more a hold-over from an early version of Forms (which had a limited number of recognized events) than current functionality.

There are four types of events in a form:

Interface Events are generated by the user s interaction with the form.
Keyboard Events are generated by the user pressing a function key or key combination that performs an action.
Internal Processing events occur as a result of run-time processing and are often generated by other events.
User-defined events.

Triggers

Triggers intercept the default behavior of the form and replace it, or add custom logic to the form. Triggers fire ”are executed ”in response to the events in the form. In most places, multiple events occur in response to actions in the form, so multiple triggers may fire in the sequence of events.

The level at which a trigger is defined determines its scope. A trigger defined at the item level applies only to that item. A trigger defined at the block level applies to every appropriate item in that block. At the form level, a trigger fires for every item in the form. For example, if a when-button-pressed trigger is placed on an individual button, it will fire only when that button is pressed. If the same trigger is placed at the block level, it will fire for all the buttons in the block. And if it is placed at the form level, it will fire for each button on the form.

Some triggers can be defined at only one level; others can be defined at multiple levels.

Note	Only one trigger of each type can exist at each level (item, block, form); to perform additional actions in response to an event, simply add code to the existing trigger.

By default, Forms executes the trigger code at the lowest level (item) first. If there is no trigger for the event at the item level, forms will look at the block level, then the forms level. Only one trigger of each type will fire by default. However, you can change the way triggers interact by setting the Execution Hierarchy property for the trigger. The Execution Hierarchy property for the trigger can have the following values:

Override The default; fires the lowest level trigger fires.
Before The current trigger will fire before firing the same trigger at the next higher scope. If an item trigger and a block trigger exist, Forms will first fire the item trigger and then fire the block trigger.
After Fires the current trigger after it fires the trigger at the next higher scope.

It is very rare to change the default of OVERRIDE for triggers. This is the expected behavior of forms. However, using a high-level trigger to perform common functionality for multiple blocks or items and setting the properties in the triggers to allow them both to fire can be efficient. If you do change this property, document it well. Developers often overlook this property because it is never changed, and it can make troubleshooting very difficult.

Writing Triggers

Triggers are written using standard PL/SQL structure and syntax, and contain anonymous PL/SQL blocks. If you have no variable declarations, the BEGIN and END statements are optional; Forms will automatically add them to the block. If there are variable declaration, then the standard format of

 DECLARE BEGIN [EXCEPTION] END

is required.

Triggers can reference forms objects, Forms built-ins , and all PL/SQL syntax and DML Statements are always allowed in triggers. Triggers can refer to Forms objects by name or ID, system variables, database packages, procedures, and functions.

Types of Triggers

Trigger can be generally divided into the following categories:

Block-processing triggers Fire in response to events related to record management in a block.
Interface Event triggers Fire in response to events that occur in the form interface as a result of user interaction.
Navigational triggers Fire as Forms navigates internally through different levels of the object hierarchy, either in response to user interaction or to internal navigation.
Transactional triggers Fire in response to events that occur as a form interacts with the database. Some transactional triggers replace default behavior and allow forms to run against non-Oracle data sources.
Validation triggers Fire when Forms validates data in an item or record. Validation is performed during navigation that occurs in response to user input or programmatic control, or by default processing such as commit.
Query-time triggers Fire just before and after the execution of a query. They are used to change the behavior of queries or augment the values returned from a query.
Message Handling triggers (on-error and on-message) Fire when errors or messages are presented by the Form.
Master-detail triggers Fire when navigating between parent and child data blocks to keep all related information coordinated. These triggers are generated automatically when a master-detail relationship is created. Unless you are developing your own custom block-coordination, you should not edit these triggers.
Key triggers Fire in response to pressing a function key or combination of keys to perform an action in the form.

The next couple of sections will discuss some of the more commonly used triggers. Forms Developer has many more triggers. The Help system has a complete listing of triggers and their characteristics.

Block Processing Triggers

The following Block Processing triggers are available to the Oracle Forms 10 g developer:

When-Clear-Block Performs an action whenever Form Builder flushes the current block; that is, removes all records from the block.
When-Create-Record Performs an action whenever Form Builder attempts to create a new record in a block. For example, it s used to set complex, calculated, or data-driven default values that must be specified at run time, rather than design time.
When-Remove-Record Performs an action whenever a record is cleared or deleted. For example, it used to adjust a running total that is being calculated for all of the records displayed in a block.
When-Button-Pressed Initiates an action when an operator selects a button, either with the mouse or through keyboard selection.

Interface Event Triggers

The following Interface Event triggers are available to the Oracle Forms 10 g developer:

When-Button-Pressed Initiates an action when the user presses a button, either with the mouse or through a keyboard selection.
When-Checkbox-Changed Initiates an action when the user toggles the state of the check box, either with the mouse or with a keyboard action.
When-List-Changed Initiates an action when the user selects a value from the list item.
When-Radio-Changed Initiates an action when the user selects a radio button in a radio group.

The preceding triggers are often used to perform validation that the user has selected a valid value, or prevent changing an item if other values have not been set properly.

When-Timer-Expired Performs an action when an internal forms timer expires .
When-Image-Activated Initiates an action when the user uses the mouse to single- or double-click on an image item.
When-Image-Pressed Initiate an action when the user single- or double-clicks on an image item.
When-Window-Activated Initiates an action when the user or application activates a window.
When-Window-Closed Initiates an action when the user closes a window, or the application does so programmatically.
When-Window-Deactivated initiate an action when the window becomes deactivated as a result of another window becoming the active window
When-Window-Resized Initiates an action whenever the window is resized, either by the user or programmatically.

Navigation Triggers

The following Navigation triggers are available to the Oracle Forms 10 g developer:

Pre-Form Performs an action just before Form Developer navigates to the form from outside the form, such as at form startup.
Pre-Block Performs an action before Form Developer navigates to the block level from the form level.
Pre-Record Performs an action before Form Developer navigates to a record from the block level.
Pre-Text-Item Performs an action before navigating to a text item in the form.
Post-Text-Item Manipulates an item when Form Developer leaves the text item.
Post-Record Manipulates a record when Form Developer leaves it.
Post-Block Manipulates the current record in the block when Form Developer navigates out of a block and to another block.
Post-Form Performs an action before Form Developer navigates outside the form, such as when exiting.

When-New-Instance Triggers

The following When-New-Instance triggers are available to the Oracle Forms 10 g developer:

When-New-Form-Instance Performs an action at form startup.
When-New-Block-Instance Performs an action immediately after the input focus moves to an item in a block other than the block that previously had focus.
When-New-Record-Instance Performs an action immediately after the input focus moves to an item in a different record. If the new record is in a different block, this fires after the when-new-block-instance trigger, but before the when- new-item -instance trigger.
When-New-Item-Instance Performs an action immediately after the input focus moves to a different item. If the new item is in a different record or block, then the when-new-record-instance and when-new-block-instance triggers also fire.

Transactional Triggers

On-triggers are normally used against a non-Oracle database; or when basing blocks on PL/SQL procedures, when the default behavior of delete, insert, update, and select must be handled explicitly by code. When a block is based on a PL/BLOCK, Forms Developer will generate these triggers for you:

On-Delete Replaces the default processing for handling deleted records during transaction posting.
On-Insert Replaces the default processing for insertion of records into the database.
On-Update Replaces the default processing for handling updated records.
On-Select Replaces the default processing for opening a cursor and executing the query to identify the records in the block that are identified by the block properties.
Pre-Commit Performs an action immediately before the Post and Commit transactions are processed in the database.
Pre-Delete Manipulates a record prior to its being deleted from the database during the default Post and Commit transactions; for example, to prevent deletion of the record if certain conditions are met.
Pre-Update Validates or modifies a record prior to its being updated in the database.
Pre-Insert Manipulates a record prior to its being updated in the database.
Pre-Select Performs an action during the execute query and count query processing when the block is queried. The actual statement performed by the block can be retrieved in the pre-select trigger.
Pre-Logon Performs an action just before Forms Developer initiates the logon procedure. Usually used against a non-Oracle database.

Validation Triggers

The following When-New-Instance triggers are available to the Oracle Forms 10 g developer:

When-Validate-Item Augments the standard validation of an item performed by Forms Developer.
When-Validate-Record Augments the standard validation of a completed record.

Query Triggers

The following Query triggers are available to the Oracle Forms 10 g developer:

Pre-Query Validates the current query criteria, or provides additional query criteria programmatically, just before sending the SELECT statement to the database. It can be used to modify the query criteria by adding default values.
Post-Query Performs an action (usually a query to retrieve additional data) after fetching a record from the database.
- Fires once for each record retrieved by the block.
- Often used to populate control items or items in other blocks.

Key Triggers

Key triggers are a bit different than those triggers listed above. A predefined set of logical functions are assigned to every form. These are mapped to function keys, which are operating system specific. Every keyboard has a physical set of keys that are mapped to logical functions, but the keyboard is dependent on the type of computer and OS.

Forms cannot generally be coded to look for the press of a physical key ”say F1. Instead, Forms looks for the press of a key that results in that specific logical function ”the key that executes a query, or displays a list box, for example. You can programmatically mimic the pressing of the function key using the do-key built-in.

Key triggers change the default behavior of a function key. A function key can be disabled by writing a NULL trigger. Note that key triggers must contain explicit instructions if you want them to perform their default functionality in addition to custom logic.

Each key-trigger fires when the key combination for the corresponding function is pressed. Each key-trigger also has a corresponding built-in.

Built-Ins

Built-ins are simply functions or procedures that allow PL/SQL code to interact seamlessly with Forms objects in PL/SQL. They extend PL/SQL with form-specific functionality.

Table 3-1: Key triggers and their functions
Key Trigger	Function	Built-In
Key-clrblk	Clearing the block	CLEAR_BLOCK;
Key-clrfrm	Clearing the form	CLEAR_FORM;
Key-clrrec	Clearing the record	CLEAR_RECORD;
Key-crerec	Creating a new record	CREATE_RECORD;
Key-delrec	Deleting the current record	DELETE_RECORD;
Key-up	Moving the cursor up a record	UP;
Key-down	Moving the cursor down	DOWN;
Key-next-item	Navigating to the next item	NEXT_ITEM;
Key-prev-item	Navigating to the previous item	PREVIOUS_ITEM;
Key-nxtblk	Navigating to the next block	NEXT_BLOCK;
Key-prvblk	Navigating to the previous block	PREVIOUS_BLOCK;
Key-nxtrec	Navigating to the next record	NEXT_RECORD;
Key-nxtset	Navigating to the next fetched set of records	NEXT_SET;
Key-scrdwn	Scrolling down a screen	SCROLL_DOWN;
Key-scrup	Scrolling up a screen	SCROLL_UP;
Key-commit	Committing a record	COMMIT_FORM
Key-exit	Exiting the form	EXIT_FORM
Key-entqry	Entering a query	ENTER_QUERY
Key-exeqry	Executing a query	EXECUTE_QUERY
Key-others	When any other key is pressed

Invoking Multiple Forms

Most applications consist of a number of separate forms, which each handle a specific task. These multiple forms interact seamlessly to provide the user with a single, unified GUI. In order to do this, forms must be able to invoke and run other forms. There are several built-ins that control how the application invokes multiple forms:

New_Form Closes the currently active form (after performing all validation and committing changed data) and opens a new form.
Call_Form Suspends the currently active form and opens another one. The calling form remains open, but it is in the background and cannot be interacted with. As soon as the current form exits, the calling form is resumed at the point where it was suspended . Note that committing in the newly opened form will commit all pending transactions in both (all) forms.

Note
This can take up a lot of memory, since the call stack remains open.
Open_Form Opens a completely new form, while leaving the calling form open and active as well. The user can switch between the forms. By default, the new form is opened in the same session, but it could be opened in a separate session in order to have asynchronous transactions.

Testing Built-Ins

Any built-in that could result in an application error should be explicitly tested using forms_failure, form_fatal, or form_success (these are also built-ins). It is not necessary to test all built-ins for success, but any built-in that performs navigation should be tested if there is a chance that the failure would disrupt the form. For example,

 go_block(