Page History
EXCHANGE FIELDS(#OBJECTKEY)
...
OPTION(*ALWAYS)
GROUP_BY NAME(#PANEL)
...
FIELDS(
...
#OBJECTA01 ...
...
#OBJECTANN
(
...
#AB$TABFLD *
...
INPUT *NOID))
BEGIN_LOOP
FETCH FIELDS(#PANEL)
...
FROM_FILE(OBJECT)
...
WITH_KEY(#OBJECTKEY)
IF_
...
STATUS IS_NOT(*OKAY)
...
MESSAGE 'Object to be changed cannot be found ...
...
select desired object'
MENU
ENDIF
MESSAGE '
...
Key in object changes and press Enter.'
REQUEST FIELDS(#PANEL)
...
IDENTIFY(*DESC)
CURSOR_LOC(*
...
ATFIELD #OBJECTA01)
UPDATE FIELDS(#PANEL)
...
IN_FILE(OBJECT)
MESSAGE '
...
Object has been updated with new details'
END_LOOP
Q & A
What does the program do?
It does one and only one thing. Allow the user to change the details of the object that they are working with.
What is the AB$TABFLD field for?
This example assumes that field AB$TABFLD has been defined in the Repository with input and output attribute ND (non- display) only. You can put a field like this into your dictionary. Use any name you like, there is nothing special about the name AB$TABFLD. Make it type alphanumeric, length 1.
...
It is recommended that you put a field like AB$TABFLD into the Repository, with the correct attributes and help text, and then use it in all situations like this.
Should this function be broken up into smaller functions?
Quite possibly. One of the advantages of action bar processing is that a larger array of "actions" can be presented to the user over what was often practical in menu driven systems.
For instance, the OBJECT being dealt with in this program might be an employee master file. So rather than have one conceptually large "Change Employee" pull down option / function, it might actually be broken down into a series of conceptually smaller pull down choices / functions such as "Change Address", "Change Salary", "Change Phone Numbers", etc, etc.
Often these smaller functions are more readily identified by users with their workplace practices, rather than the "Change Employee" type of function, which has a very subtle hint of data modeling in it (ie: understanding that address details are "attributes" of an "entity" called an employee).