Oracle E-Business Suite forms use the following container objects:
Modules
Windows, including standards for modal and non-modal windows
Canvases, including standards for content and stacked canvases
Blocks
Regions
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.
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.
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.
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.
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.
Apply the WINDOW property class to all non-modal windows.
Always enter the name of the content canvas associated with the window.
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.
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.
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
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 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.
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.
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:
app_window.set_window_position('<window_name>','CENTER');
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:
OK - Closes a window. In some cases, it may perform a commit as well.
Tip: A specific verb can be substituted in place of "OK". For instance, in a windo designed to record additional information before posting, buttons of "Post" and "Cancel" are clearer to the user than just "OK" and "Cancel".
Cancel - Clears the data without asking for confirmation, and closes the window.
Apply - Process the changes made in the window, but does not close it.
Window Close Box - Performs the same action as the "Cancel" button.
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:
go_block('LINES');
hide_window('APPROVE_LINES');
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.
This section describes content canvases.
You should apply the CANVAS property class to all content canvases.
You should size the content canvas the same as the window it is shown in.
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.
Stacked canvases should use the CANVAS_STACKED property class to enforce the correct behavior.
Stacked canvases should adhere to these display characteristics:
Only the one stacked canvas that is to be shown when its window is first opened should be set to Visible.
Stacked canvases always have Raise on Entry set to Yes.
Canvases stacked on top of each other (as in alternative regions) should all be the same size.
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:
Context Blocks
Dialog Blocks
Blocks With No Base Table
Multi-Record Blocks
Single-Record Blocks
Combination Blocks
Master-Detail Relations
Dynamic WHERE Clauses
For more information, see the Oracle E-Business Suite User Interface Standards for Forms-Based Products.
Here are some general settings for blocks.
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).
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).
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 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 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
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:
The Navigation Style of the block is usually Same Record. It should never be Change Data Block.
The Next and Previous Navigation Data Blocks should be the same as the data block itself.
Set Next and Previous Navigation Item properties as necessary to keep the user inside the dialog block.
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.
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.
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.
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_standard.event('WHEN-NEW-RECORD-INSTANCE');
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:
app_exception.disabled;
See: APP_SPECIAL: Menu and Toolbar Control
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.
Set the Navigation Style to Change Record for all multi-record blocks.
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:
GO_ITEM('lines.order_line_num');
For more information, see the Oracle E-Business Suite User Interface Standards for Forms-Based Products.
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 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.
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
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.
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.
When a detail block is in a different window than its master, but the detail window is modal, the detail block should only query upon navigation to the block. Set Coordination to Deferred and AutoQuery for the relation. Do not code any logic for this relation in the OPEN_WINDOW or CLOSE_WINDOW procedure.
The first master block of a form does not autoquery unless
only a very small number of records will be returned
the query will be fast
most likely the user will operate on one or more of the queried records
To autoquery the first block of a form, code the following:
Trigger: WHEN-NEW-FORM-INSTANCE
do_key('execute_query');
Do not code anything specific to windows being iconified, even though iconifying a window that contains a master block may make it difficult to operate with a detail block.
Do not use Master-Detail cascade delete because it is an inefficient operation on the client side. It also generates triggers with hardcoded messages.
You may modify the default WHERE clause of a block at runtime for these cases:
Any query run within the block must adhere to the new criteria
Complex sub-selects of other SQL are required to query rows requested by a user.
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.
Some regions, called tabbed regions, appear only at selected times and are displayed on tab canvases.
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.