The Form Personalization feature allows you to
declaratively alter the behavior of Forms-based screens, including changing
properties, executing builtins, displaying messages, and adding menu entries.
For
each function (a form running in a particular context based on parameters
passed to it), you can specify one or more Rules. Each Rule consists of an
Event, an optional Condition, the Scope for which it applies, and one or more
Actions to perform.
Rules
can be specified as acting either at the Function level (the default) or at the
Form level. In this latter case they are applied for all functions that run the
form. When creating rules at the Form level, pay close attention to the
Sequence number and how it will blend with other rules at the function level
for the same form.
An
Event is a trigger point within a form, such as startup
(WHEN-NEW-FORM-INSTANCE), or when focus moves to a new record
(WHEN-NEW-RECORD-INSTANCE). There are standard events that almost every form
sends, and certain forms send additional product-specific events.
The
Scope is evaluated based on the current runtime context to determine if a Rule
should be processed or not. The Scope can be at the Site, Responsibility, User,
or Industry level. Each Rule can have one or more Scopes associated with it.
Each
Action consists of one of the following:
·
setting a Property, such as making a field
Required or hiding a Tab page
·
executing a Builtin, such as GO_BLOCK, DO_KEY
or FND_FUNCTION.EXECUTE
·
displaying a Message
·
enabling a menu entry
Once
Rules are defined, when the target function is run then the Rules are
automatically applied as events occur within that form.
Additionally, any change made could interfere with the base code of a form (the code that Oracle ships), thus the Support statements must be followed diligently.
