Limitations of Oracle Forms Personalization

[1] User can only change what Oracle Forms allows at run time. For example, the following cannot be changed:

1. User cannot create new items.
2. User cannot move items between canvases.
3. User cannot display an item, which is not on a canvas.
4. User cannot set certain properties such as the Data type of an Item.
5. User cannot change frames, graphics, or boilerplate.
6. User cannot hide the item that currently has focus.

[2] Form Personalization can only respond to events that are centrally processed and dispatched by APPCORE. These are limited to:

• WHEN-NEW-FORM-INSTANCE, WHEN-NEW-BLOCK-INSTANCE, WHENNEW-RECORD-INSTANCE, WHEN-NEW-ITEM-INSTANCE. These events occur as the user moves focus within the form.
• SPECIAL1 through SPECIAL45. These occur when the user selects entries from the Tools, Reports and Actions drop down menus.
• Form Personalization can only respond to events that are centrally processed and dispatched by APPCORE. These are limited to:

WHENNEW-RECORD-INSTANCE
should read
WHEN-NEW-RECORD-INSTANCE

[3] User can see only the events that are being passed by enabling the 'Show Events' option in the Custom Code menu.

[4] Certain personalization must be performed at specific events:

• To specify the Initial Value of an Item, user must perform that action in the WHEN-NEW-RECORD-INSTANCE event of the block that contains the item.
• Special menu entries can only be created at form start up (WHEN-NEW-FORM INSTANCE)

[5] Both the Personalization form and the runtime-processing engine will report errors for these cases and skip processing of them.

[6] Certain objects may not be available to user to change, or cannot be validated:

• If a Tab within a form has no items directly rendered on it, that Tab will not appear in the list of objects that user can modify. In some cases, making that Tab the active tab before invoking the Personalization feature may cause it to be detected.
• The object types GLOBAL and PARAMETER cannot be detected, thus these fields have no LOVs to restrict their input. Use the 'Validate' or 'Apply Now' buttons to determine if the values users have entered actually exist. Note that GLOBAL variables are dynamically created, so whether they exist or not can be a matter of timing.

[7] Most significantly, this may interfere with, or be overridden by, base product code; any change user make might interfere with the normal operation of the form. This can manifest itself in several ways, such as:

• User may make a personalization but it does not take effect, because there is code in the form that overrides it. In some cases user may be able to perform user personalization by moving the Trigger Event to a 'lower' level, such as block or item-level.
• User personalization may simply produce the wrong result, because user change interacted with the base code in unexpected and untested ways. At best this error will occur immediately upon the personalization being applied; at worst it could affect some later processing which does not appear to be directly related to the object or event.
• In extreme cases, user changes may prevent the form from running at all, making it difficult to open the Personalization screen to remove the offending personalization unless user turn off Custom Code. Because of this, it is critical that any change be thoroughly tested in a Test environment. See the 'Troubleshooting, Support, and Upgrade considerations' section later in this chapter for more information.

[9] Use of the Apply Now button does not always work if dependent on the results of another action.

[10] Forms Personalization is not possible for any flexfield structure or segments. 

This is a limitation of Forms Personalization on Flexfield. A Flexfield is a single field in a Form but then when you click into it and it opens up the flexfields window, the multiple fields you see is actually a user exit with multi segment values, not form fields. No Form Personalization events are passed to flexfield windows (user exits). No Form Personalization events are passed to segments inside the flexfield window (user exit). 

However, you can do a little more on Flexfields using some custom code and Forms Personalization like?

1. Make a Flexfield Segment as read only.
2. Populate a Flexfield Segment with some pre-defined value dynamically at run time business logic.
3. Can restrict users from entry in a particular segment of a Flexfield.

[11] The argument length for creating a record group must be within 2000 Characters.  A viable workaround is to create a view that contains the required SQL then use that view as the data source for the SQL creating the record group.

[12] Populating LOV dynamically from a Record Group must be against the WHEN-NEW-ITEM-INSTANCE of that LOV item.

[13] The use of the action RAISE FORM_TRIGGER_FAILURE may not work properly in some triggers.

[14] Use of Builtin Action "Raise Form_Trigger_Failure" and pressing the button "Apply Now" will show the message "One or more required fields are missing values".

[15] It is not possible to use server-side functions that have OUT parameters as the condition to execute the actions.

[16] Expected user is an Admin/Developer

• Knowledge of Oracle Developer is extremely desirable
• Knowledge of PL/SQL, Coding Standards and/or APIs required in some cases.

[17] Normal rules for customizations apply

• Extensive testing in a Test environment is required.
• A patch does not touch user code, but user still must re-test after applying a patch.