Skip Headers

Oracle E-Business Suite Developer's Guide
Release 12.1
Part Number E12897-04
Go to Table of Contents
Go to previous page
Go to next page

Setting the Properties of Container Objects

Setting the Properties of Container Objects

Oracle E-Business Suite forms use the following container objects:


Module properties establish an overall framework for the look and feel of each form.

For more information, see the Oracle E-Business Suite User Interface Standards for Forms-Based Products.

Property Class

The TEMPLATE form automatically applies the MODULE property class to the module. The settings of this class vary on each GUI platform.

Warning: Do not change any values set by the MODULE property class.

Module Names

Make sure that in each of your forms, the Module Name matches the file name. For example, if a form is called POXPOMPO.fmb, make sure the Module Name (visible in Oracle Forms Developer) is POXPOMPO.

This is especially important if you reference objects from your form. Zoom also relies on the Module Name being correct.

First Navigation Data Block

Set this property to the name of the first block that users visit when a form is run. Do not set to a WORLD or CONTROL block.

This property also controls where the cursor goes after a CLEAR_FORM, as well as the default "Action->Save and Proceed" behavior.


From the APPSTAND form, windows automatically inherit the proper look and feel of the GUI platform on which they are running, such as characteristics of the frame, title bar fonts, and window manager buttons. This section describes features common to all Oracle E-Business Suite windows, as well as behaviors for modal and non-modal windows.


The ROOT_WINDOW is a special Oracle Forms window that behaves differently from other windows. Do not use the ROOT_WINDOW, because it interferes with the proper functioning of the toolbar and other standard Oracle E-Business Suite objects.

For more information, see the Oracle E-Business Suite User Interface Standards for Forms-Based Products.

Non-Modal Windows

A non-modal window (a "regular window") allows the user to interact with any other window, as well as the toolbar and the menu. Non-modal windows are used for the display of most application entities.

For more information, see the Oracle E-Business Suite User Interface Standards for Forms-Based Products.

Property Class

Apply the WINDOW property class to all non-modal windows.

Primary Canvas

Always enter the name of the content canvas associated with the window.

Positioning (X, Y)

Non-modal windows can be positioned in a variety of styles. Code all the logic that positions windows in the APP_CUSTOM.OPEN_ WINDOW procedure, and any event that would cause a window to open must call that procedure (for example, pressing a Drill-down Record Indicator, pressing the Open button of a combination block, or pressing a button that leads to a child entity in a different window).

The first window(s) of a form that appears when the form is invoked must also be programmatically positioned.


The Oracle E-Business Suite User Interface Standards for Forms-Based Products describes how to title your non-modal windows, including rules for showing context information.

Some window titles include context information that changes according to the data displayed. Usually, the main entity window title does not change, but titles of detail windows do change to show context information. For these detail windows, you use an APPCORE window titling routine. For all windows, you also set the Title property of the window to the base title you want.

Size (Width, Height)

The maximum allowed window size is 10.3 inches by 6.25 inches. Any size smaller than this is allowed, down to a minimum of approximately two inches by two inches. If you do not need the maximum size for your window items, you should make the window smaller to leave the user with extra space for other windows on the screen.


You must explicitly code the closing behavior for your windows to ensure that windows do not close while in Enter Query mode, closing the first window of a form closes the entire form, and other standard behaviors. You code the closing behavior in the APP_CUSTOM.CLOSE_WINDOW procedure.

Closing Windows

Window Opening

If you have logic that must occur when a window opens, place the logic in APP_CUSTOM.OPEN_WINDOW. You must add logic to control block coordination and to position windows.

Tip: You do not need to explicitly show a window. A GO_BLOCK to a block within a window opens the window automatically.

See: Coding Master-Detail Relations

Disabling Specific Menu Entries

If for certain windows you want to disable some menu entries, use the APP_SPECIAL routines to do so. Enable and disable SAVE to control the "File->Save" and "File->Save and Enter Next" menu entries. Save is automatically disabled when you call APP_FORM.QUERY_ONLY MODE.

See: APP_SPECIAL: Menu and Toolbar Control

Modal Windows

Modal windows force users to work within a single window, and then to either accept or cancel the changes they have made. Modal windows have the menu associated with them, but the user cannot have access to it. There are a few legacy screens that allow limited access to the toolbar and menu (modal windows with menu), but no new instances should be designed or coded.

For more information, see the Oracle E-Business Suite User Interface Standards for Forms-Based Products.

Property class

Property Class

Use the WINDOW_DIALOG property class to create a modal window. The WINDOW_DIALOG_WITH_MENU property class exists for backwards compatibility only, and should not be used for any new windows.

Primary Canvas

Always enter the name of the content canvas associated with the window.


Modal windows are always opened centered on the screen. They are re-centered each time they are opened.

Include the following call in the code that opens your modal window:


See: Positioning Windows Upon Opening


Modal windows can be closed with the native GUI window close mechanism. You can also explicitly close the window in your code, typically with the following buttons:

You must move the cursor to a block in a different window before closing the modal window.

Example: Trigger: WHEN-BUTTON-PRESSED on item CANCEL:


Processing KEY-Triggers

See Dialog Blocks for information on trapping specific KEY-triggers within a modal window.

See Dialog Blocks


This section describes the settings for content and stacked canvases.

For more information about the use and behavior of canvases, see the Oracle E-Business Suite User Interface Standards for Forms-Based Products.


Always enter the name of the window the canvas is shown in.

Content Canvases

This section describes content canvases.

Property Class

You should apply the CANVAS property class to all content canvases.

Size (Width, Height)

You should size the content canvas the same as the window it is shown in.

Stacked Canvases

One or more stacked canvases may be rendered in front of the content canvas of a particular window. If needed, a stacked canvas may fully occupy a window.

See Alternative Regions for a full description of stacked canvas behavior with regions.

For more information, see the Oracle E-Business Suite User Interface Standards for Forms-Based Products.

Property Class

Stacked canvases should use the CANVAS_STACKED property class to enforce the correct behavior.

Display Characteristics

Stacked canvases should adhere to these display characteristics:

The content canvas should be blank in the area that would be covered by the stacked canvases.


When multiple stacked canvases occupy the same window, and may overlap, the sequence must be set so that the proper canvases, or portions of canvases, are displayed.

Whenever possible you should explicitly hide a stacked canvas that is not visible to a user. This reduces the resources that the widgets on it may consume.


This section discusses the general settings for all blocks, as well as how to set up blocks for the following situations:

For more information, see the Oracle E-Business Suite User Interface Standards for Forms-Based Products.

General Settings

Here are some general settings for blocks.

Property Class

Use the BLOCK property class for all non-modal blocks; use BLOCK_DIALOG for blocks displayed within modal windows.

Never override the Visual Attribute Group property of this class; it varies on each platform.


If the block is based on a table or a single-table view, set Key-Mode to Unique. If the block is based on a join view, set Update Allowed to No. Ensure that at least one item in the block is marked as a primary key (set Primary Key at the item level to Yes for each item that makes up the primary key of the data block).


Delete Allowed

To prevent deletes in a block, set the Delete Allowed property for the block to No (do not code a DELREC trigger to prevent deletes).

Next and Previous Navigation Data Block

Set these properties for every navigable block. These settings affect next block and previous block navigation sequence and should not be set to CONTROL or WORLD blocks.

For the first block, set the Previous Navigation Data Block to be itself. For the last block, set the Next Navigation Data Block to be itself.

If the Next Navigation Data Block changes dynamically at runtime, you must still set the property to something logical. You decide the most logical flow of your next and previous blocks.

Context Blocks

Context blocks are shown in detail windows to provide context, and replicate fields that are shown in master windows. To create a context block, make display items that are part of the same block as the master and synchronize the context field with the master field.

Dialog Blocks

Dialog blocks are the blocks presented in modal windows. They require the user to interact with them before proceeding to other windows of the application.

See: Modal Windows

Processing KEY- Triggers

Most standard Oracle Forms functions, such as Save, Next Block, and Clear All, do not apply in a dialog block. Although the Oracle E-Business Suite menu and toolbar may not be accessible, Oracle Forms functions can still be invoked from the keyboard unless you disable them. You should disable all KEY- triggers for the block by coding a KEY-OTHERS trigger that calls APP_EXCEPTION.DISABLED, which will cause a beep when the user attempts a disabled function. You then specifically enable some functions for the block by coding the additional KEY- triggers as listed in the following table:

KEY- Trigger Code
KEY-OTHERS app_exception.disabled; (1)
KEY-NEXT-ITEM next_item;
KEY-PREVIOUS-ITEM previous_item;
KEY-CLRREC clear_record
KEY-EDIT app_standard.event('KEY-EDIT');
KEY-LISTVAL app_standard.event('KEY-LISTVAL');
KEY-ENTER enter;
KEY-HELP app_standard.event('KEY-HELP');
KEY-PRINT print;

(1) This disables every KEY- function in the block that does not have a specific KEY- trigger coded for it.

If the dialog block allows multiple records, then additional KEY- triggers should also be enabled as listed in the following table:

KEY- Trigger Code
KEY-CREREC create_record;
KEY-NXTREC next_record;
KEY-PREVREC previous_record;
KEY-UP up;
KEY-DOWN down;

Other functions may be enabled if appropriate for the specific dialog block.

In cases where most functions are enabled, just disable those that do not apply by calling APP_EXCEPTION.DISABLED in the KEY- triggers for those specific functions that you want to disable.


Navigation to items outside a dialog block must be prevented while the modal window is open. [Tab] must be restricted to fields within that window. The following guidelines prevent the user from navigating out of a dialog block:

Data Blocks With No Base Table

You may need to implement blocks that have no base table or view. Use transactional triggers (ON-INSERT, ON-LOCK, etc.) if such a block must process commits.

Do not base the block on a dummy table such as FND_DUAL.

For example, the "Move Inventory Items" form submits a concurrent request to process the data entered on the screen. Code an ON-INSERT trigger to call the concurrent process submission routine.

See: Concurrent Processing

Single-Record Data Blocks

Single-record blocks allow the user to see as many items of an entity as possible, at the tradeoff of only seeing one record at a time.

Navigation Styles

If the block has no detail blocks, or it has detail blocks but they are in different windows, the Navigation Style should be Same Record; otherwise it is Change Data Block.

Data Blocks With Only One Record Available

For data blocks with only one record of data, you may want to disable the first record, last record, previous record, and next record options on the Go menu.

To do this, code a block-level WHEN-NEW-RECORD-INSTANCE trigger (Execution Hierarchy: Override) with these lines:

 app_special.enable('SINGLE', PROPERTY_OFF);

To prevent the user from using a key to perform functions incompatible with one record blocks, code block-level KEY-DOWN, KEY-CREREC, and KEY-NXTREC triggers (Execution Hierarchy: Override) containing:


See: APP_SPECIAL: Menu and Toolbar Control

Multi-Record Blocks

Multi-record blocks allow the user to see as many records of an entity as possible, usually at the tradeoff of seeing fewer attributes of each record simultaneously.

For more information, see the Oracle E-Business Suite User Interface Standards for Forms-Based Products.

You must provide either a current record indicator or a drill-down indicator for each multi-record block, depending on whether the block supports drill-down.

Navigation Style

Set the Navigation Style to Change Record for all multi-record blocks.

Current Record Indicator

If the block does not have any detail blocks (and therefore does not support drilldown), create a current record indicator for the block as follows: Create a text item in the multi-record block. Give the text item the name "CURRENT_RECORD_INDICATOR" and apply the property class "CURRENT_RECORD_INDICATOR".

Single-clicking on the indicator moves the cursor to the first navigable field of the appropriate record. Do this by creating an item-level WHEN-NEW-ITEM-INSTANCE trigger (Execution Hierarchy: Override) on the record indicator item, and issue a GO_ITEM to the first field of the block. For example:


For more information, see the Oracle E-Business Suite User Interface Standards for Forms-Based Products.

Drill-down Indicator

If the multi-record block supports drill-down to one or more detail blocks, create a drill-down indicator as follows: Create a text item in the multi-record block. Name it "DRILLDOWN_RECORD_INDICATOR", and apply the property class "DRILLDOWN_RECORD_INDICATOR".

Add an item-level WHEN-NEW-ITEM-INSTANCE trigger (Execution Hierarchy: Override) to the drill-down indicator item. Call the same logic as the button that corresponds to the drill-down block. For Combination blocks, this should move to the Detail window. In other blocks, if there are one or more child blocks, drill-down moves you to one of them.

You should account for situations where movement to the drill-down block is currently not allowed and the corresponding button is disabled. Check for this condition in the WHEN-NEW-ITEM- INSTANCE trigger before doing the drill-down. If the drill-down is not enabled, issue a call to APP_EXCEPTION.DISABLED and navigate to the first item in the current block.

For more information, see the Oracle E-Business Suite User Interface Standards for Forms-Based Products.

Combination Blocks

Combination blocks are hybrid formats, where fields are presented in both multi-record (Summary) and single-record (Detail) formats. The Summary and Detail formats are each presented in their own window, but all of the fields of both formats are part of a single block.

Important: Do not confuse the Detail of Summary-Detail with the Detail of Master-Detail.

Buttons on the Detail window may include additional actions not available from the Summary window.

See: Oracle E-Business Suite User Interface Standards for Forms-Based Products.

Master-Detail Relations

For more information on the look and feel of master-detail relations, see the Oracle E-Business Suite User Interface Standards for Forms-Based Products.

See: Coding Master-Detail Relations

Prevent Masterless Operations

A user cannot enter or query detail records except in the context of a master record. Always set the Coordination property to Prevent Masterless Operation.

Prevent Deletion of Detail Records

Because your form should be built using underlying views instead of actual tables, you should not allow the normal Oracle Forms deletion of detail records. Instead, set the Master Deletes property of the relation to Isolated. Then, delete your detail records as part of your Delete_Row procedure in the table handler for the master table.

Other Behaviors

Dynamic WHERE Clauses

You may modify the default WHERE clause of a block at runtime for these cases:

All other cases should just populate values in the PRE-QUERY trigger.


Regions are groups of fields. Most regions are purely cosmetic, where a frame (box) surrounds a group of related fields or a frame (line) appears above a group of related fields. In these cases, there is no code impact other than making sure that once the cursor is in a region, the block tabbing order goes through all the items in one region before proceeding to other regions or fields in the block.

Tabbed Regions

Some regions, called tabbed regions, appear only at selected times and are displayed on tab canvases.

See: Coding Tabbed Regions

Overflow Regions

Overflow regions show additional fields of a multi-record block in a single-record format immediately below the multi-record fields.

Simply create these fields within the block of interest, and set the Number of Items Displayed property to 1.