Migrating Custom Forms--4.5 to 6i

Hi,
Currently i am doing a migration project ..and migrating forms...
But for migrating forms there is oracle standard process to do..but unfortunately many people didn't do that way...But this process is the recommended one.
Currently i am facing some issues with FLint60 utility...i will post them also here

1."ERROR ? Item BLOCKNAME.RADIO_BUTTON81 (Radio Group) requires Hint Text "
"ERROR ? Library Location 'APPCORE.pll' for Attached Library APPCORE must not contain a path or extension
ERROR ? Library Location 'APPDAYPK.pll' for Attached Library APPDAYPK must not contain a path or extension
Any problems like above or with the libraries just delete the libraries in the older version form
and then reattach and use the flint60 untility

2.Error like radio group hint text can be ignored

3.One important thing is check how the forms are desinged and see that they are upgraded to the 11.5.10 feautures like lov and others..This is really important make sure that your custom forms look and feel match with oracle latest apps version standards

Upgrading Custom Forms to Release 11i

This section covers upgrading custom forms built with Oracle Forms 4.5, the Oracle Applications coding standards, and Oracle Application Object Library. It applies to custom forms built to integrate with Releases 10SC, 10.7 NCA, and 11.

Upgrading your custom forms to Release 11i consists of the following basic steps:
1. On your developer client machine convert your Oracle Forms 4.5 forms to Oracle Forms 6i using the Oracle Forms 6i Form Generator and make any required changes related to converting to PL/SQL 8

If you have any library files which you attached to your form you must first convert the library files prior to attempting to upgrade your form module. To convert your 4.5 form to a 6i form load a copy of your 4.5 form into 6i form builder and save 'only', DO NOT re-compile it.
By loading the library or form module the developer will perform a number of steps to prepare the files for the new developer environment once successfully saved you may proceed the the next steps outlined below.

2. Move the newly converted 6i form to the Forms server in the $AU_TOP/forms/US directory. Use the Oracle Applications upgrade utility (flint60) on the Oracle Forms 6i .fmb file to apply changes that help your form conform to Release 11i standards.

Release 11i of applications provides an upgrade utility called flint60 which performs a number changes to custom forms previously developed for Oracle Applications 10.7SC/NCA and 11.0.x. The changes include 11i enhancements and applications coding standards verification. The utility may be run multiple times against the custom developed form during the development process.

**** This utility is only for the form module. There
**** is no such utility provide nor needed for custom
**** developed library files.

NOTE: Flint60 is a 32 bit utility that runs on your forms server tier (i.e. it will not run on any machine that is not certified as a forms server like ... Windows95 or Windows 3.11 )

To successfully run the flint60 utility, the flint60.ora file must be created and contain proper values.


Setting Up the Configuration File

The flint60 utility requires a configuration file, flint60.ora, to hold the database username and password and other information. The flint60.ora file is a simple text file that should have the following information:

server_host=your_web_server_name
message_file=location_of_the_message_help_file_on_web_server
connect=[y|n]
userid=database_username_and_password

The web server host name that will be used to access the .html log files the virtual path and filename of the message descriptions file, fnderr.html boolean that indicates whether to verify blocks against the database if database=y, then this is the ORACLE username and password to use to connect to the database.

Note that when attempting to connect to the database, flint60 uses the table ACCESSIBLE_COLUMNS (actually a public synonym for SYS.ALL_TAB_COLUMNS) to determine the constraints (data type, length, null allowed) for a database item?s column. If ACCESSIBLE_COLUMNS is inaccessible, flint60 will generate multiple fatal errors in the log file (if the option to connect to the database is selected).

Example:

server_host=www-apps.us.oracle.com
message_file=/r115/fnderr.html
connect=y
userid=apps/apps@devdb

You must set an environment variable, FLINT60_CONFIG (for Unix) that points to the flint60.ora configuration file. If the FLINT60_CONFIG environment variable is not set then flint60 will search for the file flint60.ora in the current directory. If you see the message
?LRM-00109: could not open parameter file ?? ? when you try to run flint60, then the configuration file could not be loaded. If you run the flint60 utility without the configuration file, the .html log file will not be able to provide context-sensitive links to the help file that describes each of the messages generated by flint60, and the utility may be unable to connect to the database (which would create additional errors in the log file).


Verify Your Environment

It is important to verify that you are pointing to the correct versions of Oracle Forms and Oracle Applications before running the upgrade utility, or you may get spurious or misleading error messages. For example, your environment must point to the correct versions of APPSTAND.fmb and APPCORE.pll. Ensure that the environment is configured properly and is pointing to an Oracle Forms 6i environment.
Verify that the FORMS60_PATH (Unix environment variable, or NT registry setting) points to the directories that hold the correct versions of APPSTAND.fmb and APPCORE.pll.

Ensure the DISPLAY environment variable is set and valid (for Unix only).



To run flint60 utility the command line execution would look like the
following:

Command line switches

The flint60 utility can accept one, two, or no switches on the command line, as shown:

flint60 -u .fmb .fmb ...
flint60 -uc .fmb .fmb ...
flint60 .fmb .fmb ...

-u Parameter: This is the ?upgrade? mode. Include the -u
(?upgrade?) switch if you want the flint60 utility to write a new .fmb file with any required changes.

-c Parameter: Include the -c switch if you want the flint60 utility to not clear out hint text. Use the -c switch when you are running flint60 again after the initial upgrade and you have added hint text that you do not want the utility to clear out (of the new file written by the utility because of the -u switch). If you have not added hint text manually, you do not need to use this switch. The -c switch is ignored if the -u switch is not present.

If no values or switches are passed to the flint60 ultity then this is the ?standards compliance checker? mode.
If you do not use the -u switch, the flint60 utility simply performs various checks on your form and writes out a log file listing any standards compliance errors or warnings.


Form name arguments
The flint60 utility expects form names on the command line:
flint60 -uc .fmb .fmb ...

The filenames can be fully qualified with paths and/or environment variables (for Unix):

flint60 $fnd/forms/US/.fmb
/custgldev/custgl/11.5/forms/US/.fmb ...

To run flint60 for all forms in the current directory (if using an appropriate Unix shell that expands file wildcards, such as tcsh):

flint60 *.fmb

To run flint60 for all forms in a specific directory (if using an appropriate Unix shell that expands file wildcards, such as tcsh):

flint60 $fnd/forms/US/*.fmb

If you are running the flint60 utility on Windows NT, you may need to create a .bat script to run multiple commands because NT does not support expanding command line wildcards.

Reviewing flint60 Log File Output

The flint60 utility provides a detailed log file of messages as it goes through your form. The log file is called form_filename.fmb.html, and you can read it using any standard browser. The utility provides one log file for each form, located in the current directory.

The message types are:
Status: an informational message
Action: each action taken by the flint60 utility, such as changing a
piece of boilerplate to an associated prompt

3. Correct any errors found by the upgrade utility, and run the utility again to verify your changes

When utilizing the forms upgrade utility an HTML output file is created which provides detail of the changes made to the form module. Additionally, the output file provides warning and suggested changes that should be considered for custom form development which if followed will ensure custom form is 11i Oracle look and feel.

4. Perform any required manual changes that may be necessary, such as changes to internal menu names

Performing Required Manual Changes on Your Forms


Menu calls

If you have hardcoded calls in your form that modify the default
(pulldown) menu, such as calls that enable or disable menu entries, you may need to modify your menu calls because the internal names of the menu names have changed to be consistent with the rearranged menu.
Changes to Internal Menu Names from Release 11 to Release 11i (See page 27 - 42)

You can typically find these calls by using the ?Find and Replace PL/SQL? feature in the Oracle Forms 6i Form Builder (under the Program menu choice) to search for the following strings (do not search as case sensitive):

SET_MENU_ITEM_PROPERTY
GET_MENU_ITEM_PROPERTY
FIND_MENU_ITEM
APP_SPECIAL.ENABLE

These calls must be evaluated and changed if necessary.


Toolbar block calls

If you have code in your form that calls anything in the pre-11i toolbar, such as calls to enable or disable toolbar buttons, you must modify your code. Behind the scenes, the toolbar has been reimplemented to not use a distinct TOOLBAR block. It is now part of the menu, and toolbar icons are now enabled and disabled automatically when you programmatically enable or disable menu entries using the APP_SPECIAL routines.

Changes to Internal Menu Names from Release 11 to Release 11i (See page 27 - 42)

APP_SPECIAL: Menu and Toolbar Control (See page 10 - 15)

You can typically find these calls by using the ?Find and Replace PL/SQL? feature in the Oracle Forms 6i Form Builder (under the Program menu choice) to search for the string (including the single quote and the period):

?TOOLBAR.

Note that the TOOLBAR canvas has not been removed, because it serves as a holding area for certain Oracle Applications fields (such as switcher fields).

5. Perform optional manual changes, such as converting alternative regions to tabbed regions and enhancing special menus, as desired

6. Use the Oracle Forms 6i generator to generate the .fmx file for your upgraded form

Ctrl-T will compile and generate your form. Should first be performed on you development environment to ensure that all the code compiles and has been resolved prior to loading the form into the production environment.

7. Test your upgraded form within Oracle Applications 11i To test your form you will need to run the form within the applications environment only. It is possible to run the form stand alone using the forms server and the static login html file whereas the following line in the html file would initially look like:

serverArgs="module=Q:\oa\appltst\fnd\11.0.28\forms\US\FNDSCSGN
userid=applsyspub/pub@VD11 fndnam=apps"

serverArgs="module=Q:\oa\appltst\fnd\11.0.28\forms\US\FNDSCSGN
userid=apps/apps@VD11"


Note: While it is technically possible to skip the first step and go directly to the Oracle Applications upgrade utility step, we recommend that you do the first step separately to better isolate the changes to your form should there be any problem with either upgrade step.

Folder Options in Forms -Part2

Steps to create Folder Form

Step – 1 Create Folder Objects

• Reference Folder Object

Every folder form must contain the folder objects (such as the windows that are used for saving folders and changing prompts) included in the STANDARD_FOLDER object group. If this object group does not already exist in your form, reference it from APPSTAND. $AU_TOP/au/11.5.0/forms/US/APPSTAND.fmb

• Attached the Folder library

Every folder form must have the library APPFLDR.pll attached. The library file is $APPL_TOP/au/11.5.0/resource/APPFLDR.pll.

• Create the Content/Fixed Canvas

Create a content canvas, as you would for any window. Assign it the property class CANVAS, and assign it to the appropriate window. This canvas will hold the block scroll bar, the record indicator, and the folder_open and folder_title objects. This canvas will also hold any fields that would not be part of the folder block, such as required primary key fields.

Note: The name of the content canvas cannot be a substring of the name of the stacked canvas, as this will cause errors. For example, if the content canvas is called ORDERS, then the stacked canvas cannot be called ORDERS_FOLDER, but ORDERS_MAIN and ORDERS_FOLDER would be acceptable.

• Create the Stack Canvas

Create a stacked canvas; it holds prompt fields and displayed fields of the folder block, as well as the ORDER_BY# buttons.

Determine the appropriate Y position for the top of the folder block (this corresponds to the Y position for the top of the Folder Open button and the Folder Title). This value is referred to as Y_OFFSET, and is used to calculate the correct positions for items and canvasses. Typically Y_OFFSET should be .25 inches (that is, the top of the Folder Open button should be one character down from the top of the window) if the folder is the first block in the window.

Set the following properties for the stacked canvas:

Sequence : After the content canvas.

Property Class : CANVAS_STACKED
Displayed :True for the stacked canvas that will be shown
immediately upon entering the block; False for any
others.

Window : Same as for the content canvas.

View Height :.5” + (.25” * number of rows to be displayed)

Display X Pos : .5” (May be adjusted later)

Display Y pos : Y offset + .25

View Horiz
Scroll Bar : True


Step – 2 Create Folder block item
• Folder Block Item

Create a block to hold the fields of the folder, as you would any other block. The block scroll bar must be on the content canvas.

Suggestion: Although the scroll bar must be on the content canvas, most of the fields belong on the stacked canvas. If you are using the default block functionality, this can be achieved most easily by specifying the stacked canvas when creating the default block, and then changing the Scroll Bar Canvas property after the block has been created. One or more fields may be on the content canvas. These fields must always be the leftmost fields in the block, and will not respond to folder events (e.g. Move Right, Widen, Hide). Identify which, if any, fields will be on the content canvas, and move them there. Sequence these fields before any of the fields that will be on stacked canvasses.

Adjust the Display X Position for the stacked canvas view so that it is .1” to the right of the fields on the content canvas. For each item to be displayed as part of the folder, set the properties as follows:

TYPE: Text Item, Check box or List only.

X Position: Positioned at runtime

Y Position: If on content canvas, Y_OFFSET + .5”; otherwise, .25”

Width: Set at runtime

Canvas: The content or stacked canvas

Displayed: If part of the default display, True; otherwise False. Fields on the content canvas must be Displayed.

Note: The position and width of any field on the content canvas must be set accurately in the Designer. Also, the width of a check box should be set accurately to 0.3”. Check boxes with width 0.2” are acceptable, but do not save space since APPFLDR always allocates at least 0.3” for a check box.

• Folder Switcher Item

Create a switcher field for the block. In a combination block, this should be called ’SWITCHER’, and in any other folder block, it should be called ’FOLDER_SWITCHER’. It must be sequenced first in the block, and must use the SWITCHER property class. Place it on the content/fixed canvas. This field must not have a corresponding field in the prompt block. Attached the following trigger to the switcher item:-

Trigger: WHEN–NEW–ITEM–INSTANCE (Execution Style: Override)
On field SWITCHER:

app_folder_move_cursor(’1’);

• Create Current Record Indicator/Drilldown Record Indicator

Create a record indicator for the block. It must be called either CURRENT_RECORD_INDICATOR or DRILLDOWN_RECORD_INDICATOR. Do not include a corresponding field in the prompt block. The folder code disables certain functions automatically, but it is developer responsibility to write the code to manage the indicator. The WHEN–NEW–ITEM–INSTANCE trigger for CURRENT_RECORD_INDICATOR must call
app_folder_move_cursor(’1’).

Step – 3 Create Block Level Trigger
• Trigger: WHEN–NEW–BLOCK–INSTANCE (Execution Style: Before)

app_folder.event(’WHEN–NEW–BLOCK–INSTANCE’);

This trigger instantiates the folder block(if necessary), attempting to load the user’s default if on exists.

• Trigger: KEY-NEXT-ITEM

app_folder.event (’KEY–NEXT–ITEM’);

This trigger navigates to the next folder–sequenced item. Moves to next record if needed. Fire in Enter Query mode must be TRUE.

• Trigger: KEY-PREV-ITEM

app_folder.event(’KEY–PREV–ITEM’);

This trigger navigates to the prior folder–sequenced item. Moves to
prior record if needed. Fire in Enter Query mode must be TRUE.

• Trigger: PRE–BLOCK (Execution Style: Before)

app_folder.event(’PRE–BLOCK’);

This trigger establishes values for the folder block (when more than one is defined). It re-enables the folder menu upon entering the block.

• Trigger: POST–BLOCK (Execution Style: Before)

app_folder.event(’POST–BLOCK’);

This call disables the folder menu.

• Trigger: PRE–QUERY (Execution Style: Before)

app_folder.event(’PRE–QUERY’);

This call builds the order by clause for the query.

• Trigger: POS–QUERY (Execution Style: Before)

app_folder.event(’POST–QUERY’);

If the folder block is the master of a master–detail relationship, this trigger is required. It extracts the WHERE clause from SYSTEM.LAST_QUERY. Without this trigger, the detail block’s query can be extracted instead, which can lead to saving an invalid query with the folder.

• Trigger: User–named trigger FOLDER_RETURN_ACTION

<>

This trigger is fired each time the folder does certain operations that you may need to further process. ’global.folder_action’ contains the name of the process, and ’global.folder_field’ holds the name of the relevant field, if any, stripped of the block name. Specific callbacks may populate other global variables. The FOLDER_RETURN_ACTION trigger is optional. You should code it if you need to perform logic on any of the supported events.

Example:-
Following is code written in FOLDER_RETURN_ACTION trigger to allow update for ‘COL1’, ‘COL2’ and ‘COL3’ in the folder block:-

DECLARE
field_name VARCHAR2(30);
BEGIN
IF (:global.folder_action = ’SHOW–FIELD’) THEN
field_name:= NAME_IN(’global.folder_field’);
IF (field_name IN (’COL1’, ’COL2’, ’COL3’)) THEN
app_item_property.set_property (
’’||’.’||field_name,
ALTERABLE,
PROPERTY_ON);
END IF;
END IF;
END;

Step – 4 Create Prompt Block
Create a one record block to hold the fields that act as prompts for the folder block. For every item in the folder block that may be displayed, the prompt block must contain an item of the same name (except for the record indicator and the switcher). The initial settings of the prompts drive the layout of the Default Screen, including item width and tabbing sequence.

Typically one would name the prompt block _PROMPT, for example, ORDERS_PROMPT.

Each ’prompt’ field must have the following characteristics:

Property Class: DYNAMIC_PROMPT
Sequence: Must match the name of an item in the folder block. Sequence the first
set of fields to be displayed properly, starting at 1. This drives the
folder TAB order.
X Position: Positioned at runtime.
Y Position: .05.

Width: Dictates the width of the corresponding field. Make sure the width is adequate to display the text for the prompt fully. The width only needs to
account for English text – no translation expansion space is needed. Specifying the width as 0.1” causes it to adjust automatically based on the text it contains. For checkboxes, specify a width of 0.1”

Alignment: Usually Start, but follows alignment of data in corresponding folder
block field. Prompts for check boxes are always Center aligned.

Canvas: Stacked canvas.

Default: The text for the prompt. The translation tool translates this
automatically.

Displayed: True only for those fields you want displayed on the default screen;
otherwise, False.


Create Special Fields in Prompt Block

The following special fields must exist in the prompt block:-

Field: FOLDER_OPEN
PROPERTY CLASS: FOLDER_OPEN
X POSITION: 0.1”
Y POSITION: Y_OFFSET
CANVAS: content canvas

Field: FOLDER_TITLE
PROPERTY CLASS: DYNAMIC_TITLE
X POSITION: 0.4”
WIDTH: 4”
Y POSITION: Y_OFFSET +.05
CANVAS: content canvas

Field: FOLDER_DUMMY
PROPERTY CLASS: FOLDER_DUMMY
CANVAS: TOOLBAR

Field: ORDER_BY1,ORDER_BY2,ORDER_BY3
PROPERTY CLASS: FOLDER_ORDERBY
X POSITION: Set at runtime.
Y POSITION: For content canvas Y_OFFSET+.5+(.25*Rows)
For stack canvas .25+(.25*Rows)
CANVAS: If it’s a fixed field specify content canvas otherwise specify stack
canvas.

Step – 5 Code Form Level Trigger
The following form–level triggers must exist in order for a folder block to operate correctly:

• Trigger: WHEN–WINDOW–RESIZED:

IF :system.event_window IN (’<>’) THEN
app_folder.event(’WHEN–WINDOW–RESIZED’);
END IF;


• Trigger: KEY–CLRFRM:

app_folder.event(’KEY–CLRFRM’);

This call must be made anywhere a clear_form is issued. This cause the folder code to repaint the prompts and folder titles as if they were normal boilerplate.

• Trigger: WHEN–NEW–FORM–INSTANCE:

app_folder.define_folder_block('OBJECT NAME',
’’,
’’,
’’
’’,
[’’]);

Note: All parameters must be passed in UPPERCASE.

Example:
App_flolder.define_folder_block(‘PO_HEADER’
,’POHEADER’
,’POHEADER_PROMPT’
,’POHEADER_STK’
,POHEADER_MAIN’)

Choose the object name carefully; it must be unique across all products. Prefix it with the application short name, for example ’FND_ALERTS’. This object name identifies all folder definitions that users define and save for your folder, and it appears in the Administer Folders form as the Folder Set, so you should make the object name descriptive and readable.

’DISABLED FUNCTIONS’ can be a string combining any of the following. Specifying that a function is disabled prevents the user from performing it.

• OPEN
• TOOLS: Disables everything except OPEN. Note that if the profile FOLDERS:ALLOW_CUSTOMIZATION is ’N’, all tools are automatically disabled except Open.

• ORDERBY
• NEW
• SAVE: Disables Save and Save As.

• AUTOQUERY: Should be disabled for any detail block.

• PUBLIC
• DEFAULT
• DELETE
• SHOW
• HIDE
• MOVE
• WIDEN
• SHRINK
• AUTOSIZE
• PROMPT
• QUERY

Following example will disable ‘ORDER BY’ and ‘HIDE’ function in the folder form:

App_flolder.define_folder_block(‘PO_HEADER’
,’POHEADER’
,’POHEADER_PROMPT’
,’POHEADER_STK’
, POHEADER_MAIN’
,’ORDERBY HIDE’);

• User-named Trigger: FOLDER_ACTION

app_folder.event(:global.folder_action);

Do not insert additional code in this trigger. It is used to allow the menu and folder toolbar to communicate with the folder library that is attached to the form.

• User-named Trigger: FOLDER_RETURN_ACTION
NULL;

This trigger must exist at form–level to handle the case in which it has not been coded at block–level.



The FOLDER_RETURN_ACTION trigger supports the following events:

• SHOW_FIELD: The field in :global.folder_field has just been made visible. In updateable blocks, you may need to set some properties (such as Update Allowed, Required, etc.). Fields can become visible in Enter Query mode or normal mode. When a folder is opened, all fields currently displayed are hidden, even if they are in the new folder; thus this call is made for each field as it is redisplayed.

• ADD_FILED: Populates :global.folder_field. Called at the end of a user–initiated ’Show Field’ event that results in a field being displayed. The ’SHOW–FIELD’ callback is also triggered before this callback.

• HIDE_FIELD: Populates :global.folder_field. Called at the end of a user–initiated ’Hide Field’ event that results in a field being hidden.

• OPEN_FOLDER: Called at the end of an ’Open Folder’ event that results in a folder being loaded, but before the folder autoqueries. Populates global.folder_id.

• SET-WHERE-CLAUSE: Called during a ’Save Folder’ event, before setting the where clause that will be saved with the folder. Sets global.folder_action_allowed ’TRUE’. If the value of :global.folder_action_allowed is changed to anything but ‘TRUE’ by the FOLDER_RETURN_ACTION trigger, the WHERE clause saved with the folder is null.

• RESET-WHERE-CLAUSE: Called when the block WHERE clause is set back to the developer’s WHERE clause, because the user has selected Folder–>Reset query from the menu, or because the user has selected Folder–>New from the menu.

• SAVE-FOLDER: Called at the end of a ’Save Folder’ event, immediately before the Commit. Populates :global.folder_id.

• DELETE-FOLDER: Called during a ’Delete Folder’ event, immediately before the Commit. Populates :global.folder_id.

• CONFIRM-HIDE-FIELD: Called during a user–initiated ’Hide Field’ event, immediately after doing all other checks that the field can be cut (for example, it is not on the content or fixed canvas, it is not the only field on the stacked canvas, etc.). The variable ’global.folder_action_allowed’ is seeded with ’TRUE’. If this variable is changed to anything but ’TRUE’, the action is aborted and the user cannot hide the field. By default, if the user attempts to hide a required field, CONFIRM–HIDE-FIELD automatically prevents it, and users are allowed to hide non–required fields. You can override this behavior by changing the value of :global.folder_action_allowed to either ’TRUE’ (allow hiding) or ’FALSE’ (prevent hiding non–required fields) in the CONFIRM–HIDE–FIELD callback to the FOLDER_RETURN_ACTION trigger.

• AUTOQUERY: Called when a folder loads and automatically executes a query.

• CONFIRM-AUTOQUERY: Called when a folder that is designed to autoquery opens. ’GLOBAL.FOLDER_ACTION_ALLOWED’ is seeded with ’TRUE’. If this variable is changed to anything but ’TRUE’, the folder does not autoquery.

Example: Prevent Hiding a Field
Prevent the user from hiding the (non–required) ’PERIOD_NAME’ field:

Trigger: FOLDER_RETURN_ACTION (block–level):
IF(:global.folder_action = ’CONFIRM–HIDE–FIELD’) THEN
IF :global.folder_field = ’PERIOD_NAME’ THEN
:global.folder_action_allowed := ’FALSE’;
END IF;
END IF;

Folder Options in Custom Forms--Part1

Folder option is one of the good concepts available to reduce the Future customization in many custom Forms.Here i am putting basic functionality of
the folders and will try to put the simple steps to do them.
These thing are available in the metalink with a little search but i putting for ready reference...for technical people

Functions of the Folder

Folders provide the following functions to the user:

• Customizable display of retrieved data, including:

Columns to be displayed
Width of columns to be displayed
Sequence of columns
Prompts associated with columns
Record ordering (with some exceptions)

• Persistent storage of folder definitions
• Automatic rerun of a previously defined query
• Public and private access to persistent configurations
• Default configuration specification

In addition, system administrators can prevent users from creating or modifying folders by setting the profile option FOLDERS: ALLOW_CUSTOMIZATION to ’N’. This setting disables all folder functions (except opening a predefined folder) for individual users.

Actions in Folder Forms

Folder form allows the user to perform the following functions:

• New: Creates a new folder. The user must enter a new, unique (per entity and user) folder name. This function is not available at enter query mode.

• Open: Loads a previously defined folder. A user can select from a list of his own folders, and any public folders, for the current entity.

• Save/Save As: Saves the current folder. If it has never been saved then revert to ‘Save As’ functionality.

• Delete: Allows a user to delete any folder that they created for the current entity. If another user is referencing the folder as their default, that reference is deleted as well.

• Show Field: Opens an LOV displaying fields that can be shown and are not currently shown. Selecting a value adds the field after the current cursor position.

• Hide Field: Hides the current field. The cursor moves to the field sequenced after the field that was just hidden. By default, required fields cannot be hidden.

• Move Right: Swaps the current field with the one to its right.

• Move Left: Swaps the current field with the one to its left.

• Widen: Increases the width of the current field, up to a maximum size of 20 inches, in .2 inch increments.

• Shrink: Decreases the width of the current field, to a minimum size of 0.3 inches, in .2 inch increments.

• Auto Size: Sizes each stacked–canvas field based on a small sample of records within the block. Uses the prompt width to establish a minimum width. Lists are sized based on the elements they contain, and check boxes are sized based on the prompt only. This function is not available in ‘Enter Query’ mode.

• Show Order By: Allows the user to toggle the order by buttons on and off. When they are shown, the user can set the ordering of first three base-table items currently shown. Each column can be set to Ascending, Descending, or Exclude. The three settings are applied left–to–right when data is fetched and sorted.

• View Query: Allows the user to view the WHERE clause of the folder.

• Reset Query: Clears the current WHERE clause. Similar to New, except that the current folder name and all of its definitions are retained.

Following are the feature which developer can customize:

• Developers can disable all folder functions independently. For instance, a developer could create a folder that prevents the user from moving fields, setting the ordering, and specifying that a folder can autoquery upon being opened.

• Developers can use the folder technology to lay out a block, but not expose any folder functions to the user.

• Developers can prevent users from hiding specific fields. This allows including mandatory fields in enterable blocks (mandatory fields should always appear).

• Most of the folder form functionality customization is done in user defined trigger ‘Folder Return Action‘ which comes with folder form template.

Behavior of a Folder Block

• Instead of boilerplate text, the prompts are actually display items in a single row block. The prompts are all painted on a single line.

• The initial settings of the prompts drive the layout of the Default Screen, including item width and tabbing sequence.

• Some field properties, including widths, X–positions, and prompts are set at runtime. Any values that remain static while the form is run are the responsibility of the developer. These include visual attributes, Y–positions, etc.

• The descriptive flexfield must exist on the stacked canvas, rather than the content or fixed canvas where it is always visible, so that the user can resize, move, and label it as needed.