For reader not yet familiar with Form Personalization, here is some summary information:
SECURING ACCESS AND TESTING
When using Form Personalization, it is recommended to take some precautions when implementing it.
1. Only trusted users should have access to this feature. Use the system profiles:'Hide Diagnostics
menu entry' and 'Utilities:Diagnostics' to control the visibility of the menu and the direct access to
the feature (user requires Apps password or not?);
2. It is a good idea to test all Form Personalizations in a DEV or TEST environment before moving
them to a Production environment. Remember that changes made could impact or interfere with
the base code of a form;
3. Follow diligently the Support statements communicated by Oracle.
OVERVIEW AND BASIC CONCEPTS
Form Personalization is a declarative feature that alter the behavior of Oracle Forms-based screens,
including changing properties, executing built-ins, displaying messages, and adding menu entries.
RULES
For each function, 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.
An Event is a trigger point within a form, such as a startup (WHEN-NEW-FORM-INSTANCE), or a new
record (WHEN-NEW-RECORD-INSTANCE). Oracle forms sends standard and product-specific events.
A Condition is an optional SQL code fragment that is evaluated when an Event occurs. If the Condition
evaluates to TRUE then the Actions are processed.
A Scope is evaluated based on the current runtime context to determine if a Rule should be processed or
not. The Scope can be Site, Responsibility or User. Each Rule can have one or more Scopes associated
with it. When defining new Rules in your DEV or TEST environment, I recommend setting the Scope to
your User first just to be safe. If all is well with your personalization, then proceed in setting the Scope to
it's intended level. If a Rule has a context of "Site", it will apply for everyone. A Rule with a context of
Responsibility doesn't override Site. A Rule with a context of User doesn't override Site or Responsibility.
ACTIONS
Each Action consists of 'Setting a property', such as making a required field or hiding a Tab
page, 'Executing a Built-in', such as GO_BLOCK, DO_KEY or END_FUNCTION.EXECUTE, 'Displaying a
Message' or 'Enabling a Special menu entry', such as a zoom.
Once Rules are defined, save and close the form and re-run the function (the form). Then the Rules are
automatically applied as Events occur within that form.
EXAMPLE OF A BASIC FORM PERSONALIZATION
For this example, we will define a basic Forms Personalization by hiding the Person, Customer and Fax
fields of the User form. Follow the following steps.
Responsibility: System Administrator
1 - Ensure to set system profile 'Hide Diagnostics menu entry' to 'No' and'Utilities:Diagnostics' to 'Yes' at
the user level.
2 - Open the Users form. (N) Security > User > Define.
3 - This is the basic Users form as shown here:
4 - From the menu, select (M) Help > Diagnostics > Custom Code > Personalize.
5 - If some Rules are already defined in the Users form, you will see them this window (as in this
example).
6 - Add a new Rule by selecting (M) File > New.
7 - This is the Form Personalisation form and it's Rules already defined. We will be adding seq. 40.
A - Rules Seq.: 40
B - Description: Hide Person, Customer and Fax fields
C - Trigger Event: WHEN-NEW-FORM-INSTANCE
D - Context or Scope: Set at User level and enter your user in the Value field
E - Select the Actions tab. This is the Actions tab of Rule seq. 40
F - Action Seq.: 1
G - Type: Property
H - Object Type: Item
I - Select the Select By Text button
J - Select the Person (Users) item from the LOV
K - Property Name: DISPLAYED
L - Value: False
M - Save your work
N - When you are done, it should look like this:
O - Repeat Steps F to L for the Customer and Fax items. Save all of your work. It should now look like
this:
P - Close the Form Personalization form, close the User form and reopen it. Your User form should now
look like this: Notice that the User, Customer and Fax fields are no longer displayed.
Other basic Forms Personalization are just as easy as this example, such as changing prompts,
concealing data or hiding tabs.
On my next entry, I will try to cover an intermediate Form Personalization as an example. Elements such
as triggers, conditions, sequences, contexts, string evaluation, multi-lingual issues, common actions and
debugging will be covered.
