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.
Attention: 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.