9.18.3 Sample Program: Changing an Object
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 data dictionary 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 appears on the input capable screen panel created by the REQUEST command as the last field on the screen. Since it has no identification, and attribute ND, the user cannot see it or anything that they type into it. It is effectively invisible to the user, other than for the fact that the cursor will tab into the field if they tab around the panel body / action bar.
It is positioned as the last field on the panel body to prevent the user from accidentally tabbing into the action bar when they modify the last visible field on the panel body (e.g.: OBJECTANN).
Imagine that field AB$TABFLD was not on the screen panel.
If field OBJECTANN was numeric and had attribute FE (field exit required) or RB (right adjust and blank fill), then imagine what happens when the user changes the field's value.
They change the value and are forced to use the field exit key. Where does the cursor go now? Straight up to the first action bar option. What happens when they press enter? It is interpreted as a switch to action bar request because of the cursor location.
What the user really wanted to do was update the OBJECT file.
This is why AB$TABFLD is used. In this scenario, the use of the field exit key in field OBJECTANN would tab the cursor into the invisible "dummy" field. When the user pressed enter, the cursor would still be in the panel body, so the users request would be interpreted correctly.
It is recommended that you put a field like AB$TABFLD into the data dictionary, 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).