Oracle Applications
forms use the following container objects:
Modules
Module properties
establish an overall framework for the look and feel of each form.
Property Class
The TEMPLATE form
automatically applies the MODULE property class to the module. The settings of
this class vary on each GUI platform.
Module Names
Make sure that in each
of your forms, the Module Name matches the file name. For
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.
Windows
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 Applications windows, as well as behaviors for modal and
non-modal windows.
ROOT_WINDOW
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 Applications objects.
For more information,
see the Oracle Applications 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 Applications 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.
Title
The Oracle Applications 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.
Closing
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, page
7-2
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, page 7-4
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, page 10-11
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 Applications 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.
Position
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, page 7-1
Closing
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');
Processing
KEY-Triggers
See Dialog Blocks for
information on trapping specific KEY-triggers within a modal window.
See Dialog Blocks,
page 5-8
Canvases
This section describes
the settings for content and stacked canvases.
For more information
about the use and behavior of canvases, see the Oracle Applications User Interface Standards for Forms-Based Products.
Window
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, page 7-21 for a full description of stacked canvas behavior with
regions.
For more information,
see the Oracle Applications 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:
•
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.
Sequence
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.
Blocks
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 Applications 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.
Key-Mode
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).
Views, page 3-6
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.
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 Applications 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
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.
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.
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_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 , page 10-11
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 Applications 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".
Oracle Applications Developer's Guide
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 Applications 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, page 7-6, 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 Applications 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 Applications 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
Setting the
Properties of Container Objects
Applications User Interface Standards for Forms-Based
Products.
See: Coding
Master-Detail Relations, page 7-4
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
•
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.
Dynamic WHERE Clauses
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.
Oracle Applications Developer's Guide
All other cases should
just populate values in the PRE-QUERY trigger.
Regions
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, page 7-9
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.
