9.18.2 Sample Program: Displaying Details of an Object
EXCHANGE FIELDS(#OBJECTKEY) OPTION(*ALWAYS)
GROUP_BY NAME(#PANEL) FIELDS(#OBJECTA01 ... #OBJECTANN)
BEGIN_LOOP
FETCH FIELDS(#PANEL) FROM_FILE(OBJECT)
WITH_KEY(#OBJECTKEY)
IF_STATUS IS_NOT(*OKAY)
MESSAGE 'Object to be displayed cannot be found .. .
select desired object'
MENU
ENDIF
DISPLAY FIELDS(#PANEL) IDENTIFY(*DESC)
CURSOR_LOC(*ATFIELD #OBJECTA01)
END_LOOP
Q & A
What does the program do?
It does only one thing. Allow the user to display the details of the object that they are working with.
Should it be enhanced to allow the user to change the object?
Probably not as Action bar programs should be designed to perform only one "action".
If I could have validated the "key" in the select object program I would not have had to code the "not found" check here?
No, that's not true. Even if the check could have been put into the object selection routine first, you would still need it in this program.
Some reasons: User invokes this program before selecting the object required, or, another user deletes the object between the "Select" and "Display" actions.
Overriding reason: without checking for the "not found" situation this program could not be called robust. Additionally, it is relying on another routine to be executed first. This is a clear violation of its self-containment and non-reliance on the pre or post execution of other routines.
What does the MENU command do?
It transfers control back to the process logical "menu", which in this application is actually being presented to the user as an action bar.
In other words, it cause the "action bar" to receive control and display the error message.
The user can then select the desired (or suggested) action from the action bar to correct the problem.
Does this mean more screen interactions when the user makes a keying error when typing in the "key" in the "Select" routine?
Yes it does.
There would be one more. The user would have to choose the "Select" option again and correct the "key" value.
However, the complexity of the application has to be played off against the chance of the error occurring and the degree of disruption the way it is handled causes.
In this case the chances are moderate, and the disruption is nil, so there is no real problem: just a different and simpler way of doing things.
Can I include lists on the screen panel as well?
Yes. This is just a simplistic generic example.