10.6.1 Pull Down Definition (for Each Action Bar Option Defined)

Each action bar option defined must have an associated pull down menu.

The pull down menu can have from 1 to 9 choices defined in it.

Each individual pull down choice must have the following things defined to make it a usable choice:

No (Sequence Number)

Specifies the number associated with the pull down choice. It cannot be changed. To reorder choices in a pull down you must over type the details. Deleted choices cause following choices to move up so that all choices are always numbered consecutively.

Description

Specifies the text that is to appear in the pull down to identify this pull down choice. Some things to note are:

• Use upper and lower case characters.

• Support for bi-directional and DBCS languages is provided.

• Conform to the CUA 1989 guidelines.

• CUA has guidelines for standard choices.

• Include "Fnn" to identify accelerator keys (where required).

• Include "..." ellipses for resulting pop-ups (where required).

• The help pull down is automatic. You do not have to define it.

AK (Accelerator Key)

Specifies the accelerator key that is to be associated with this pull down choice. Some things to note are:

• Accelerator keys are optional.

• Use values in range 01 to 24 only to identify an accelerator key.

• Avoid conflicts with other key assignments. This is not checked.

• Avoid overuse. They will confuse users and complicate the system.

• Conform to the CUA 1989 guidelines.

• They are activated on any panel showing this action bar.

• Develop standards for accelerator key assignments anduse.

PD$OPT Field Value

PD$OPT is a field defined in the LANSA Repository. Some things to note about the value you specify here are:

• If it isn't in the dictionary, define it as alpha (length 3).

• The value you specify here is placed into field PD$OPT when the pull down choice is used.

• Do not use values CUR or ALL, as they are reserved to mean "current" and "all" to built in function SET_ACTION_BAR.

• The field is accessible to RDML functions.

• Allows them to decide exactly which pull down choice was used to cause them to be invoked.

• One RDML function handling multiple pull down choices can have good performance implications. Refer to 10.18.4 Sample Program: All 3 Functions in One Program for an example of this programming technique.

• Value specified should be unique within this pull down, and preferably, within the entire action bar.

• Standards for PD$OPT values should be established.

IA (Initial Availability)

Specifies whether or not this pull down choice is to be made available on the initial invocation of the action bar. Some things to note about this option are:

• Leave as blank or enter Y to specify initial availability.

• Specify as N to cause initial non-availability.

• Unavailable pull down choices are shown in blue and have their associated selection numbers replaced by an "*".

• Unavailable and "not authorized" are not the same thing.

• RDML program access to make pull down choices available/ unavailable is provided by the SET_ACTION_BAR built in function.

Associated With

Specifies which function/process/special entry is to be invoked when the pull down choice is selected from the pull down menu.

The following is worth noting about this link between the action bar control table and the function/process/special entry it causes to be invoked:

• An RDML function from the current process can be invoked from the pull down menu. This is by far the most common type of action that results from using a pull down choice. The function will have an action bar identical to the action bar that caused it to be invoked.

• An RDML function from another process can be invoked from the pull down menu. This is not a commonly used technique, because the function may not have an action bar, or if it does, it will be the action bar of its parent process, not the action bar that actually invoked it. The non-appearance, or change in layout and content, of the action bar can be confusing to developers and end users alike, explaining why this technique is rarely used.

• Another RDML process can be invoked from the pull down menu. The invoked process may appear as a menu, or as another action bar, depending upon how it was defined. This facility allows multiple action bars to be built in a "hierarchy".

• A special entry can be invoked from the action bar. The special entry facility (described in the LANSA for iSeries User Guide) allows any IBM i command to be invoked from an action bar, including calls to 3GL application programs.

• The same function/process/special entry can be used in more than one pull down choice.

• What happens when the selected choice is used depends entirely upon the function/process/special entry.

• Being invoked from an action bar has panel design ramifications for RDML functions. For instance, a function will effectively lose the use of from 2 to 4 lines on the top of the screen panel to allow the action bar to be displayed.

The following table indicates amendment actions that can be made to the action bar control table and the type of (re)compilation activity that would normally be required:

Type Of Change To The Action Bar Control Table	Objects To (Re)Compile
More action bar options cause another line to be used on all screen panel(s).	All associated RDML functions. Process (if compiled).
More action bar options do not  cause another line to be used.	Process (if compiled).
More pull down choices.	Process (if compiled).
Action bar descriptions and  any other action bar value.	Process (if compiled).
Pull down descriptions and  any other pull down value.	Process (if compiled).