9.18.1 Sample Program: Selecting An Object
EXCHANGE FIELDS(#OBJECTKEY) OPTION(*ALWAYS)
BEGIN_LOOP
REQUEST FIELDS(#OBJECTKEY) IDENTIFY(*DESC)
CURSOR_LOC(*ATFIELD #OBJECTKEY)
END_LOOP
Q & A
What does the program do?
It does one and only one thing. Allow the user to identify the object that they wish to work with by typing in its "key".
What if the user doesn't know the "key" value?
Then they would use the prompt key to search through the list of objects in some order and choose the one they wish to work with. This feature is available via normal LANSA prompt key handling described in other sections of this guide. Inclusion of other advanced CUA features like prompting is vital to simple, yet highly functional action bar applications.
Can I validate the "key" that they specify?
You can, but the validation logic would only be executed if the user pressed the Enter key.
It is highly likely that the user will type in the "key", move the cursor up to the action bar and select the "action" that they wish to take on the object, before pressing enter.
In this case, this particular function never regains control after executing the DISPLAY command. The user chooses another function, causing this one to end, and the new one to start.
Does this mean an invalid "key" can be accepted?
It sure does. However, this is not a problem because all functions in an action bar are designed to be highly robust, self contained applications that never trust the fact that another function has been run before them, or will run after them.
So if the user keyed in an invalid "key", moved to the action bar and chose something like "Display Object", then the "Display Object" routine would quite easily handle the "not found" situation with an appropriate error message (e.g.: Object to be displayed cannot be found ... select desired object')
Why is the CURSOR_LOC(*ATFIELD #OBJECTKEY) parameter used?
You will find that you have to use the CURSOR_LOC parameter on most DISPLAY or REQUEST commands that are part of an action bar process.
The reason is simple, if you leave the parameter off the command, the operating system will position the cursor up to the first option in the action bar (by default). In most cases you actually want the cursor to position to the first field in the "panel body", so the CURSOR_LOC parameter is required, even if all the fields on the panel are output only fields.
How does the program ever end?
This program has an apparently endless loop.
However, it can be ended by the Exit key, the Cancel key or by the user switching to the action bar and choosing to use some other function by selecting a choice from a pull down.
An accelerator key may be used as well, which is functionally identical to choosing from a pull down.
What program runs after this program?
That's up to the user controlling the application, and is of no concern to this particular program.
Action bar functions are small, robust and self contained. They do not ever trust (or try to control) what happens before or after they execute.
This is the "non-procedural" component of action bar programming. Just how the user can get from one function to another is not immediately apparent from the procedural components of the code.
Once you are comfortable with the concept that the "user drives the application" you should find that your programming tasks are actually much simpler than in a fully procedural system.
If they are not, or you are having conceptual problems with the way action bars work, or you find you are generating large amounts of code, please do not hesitate to contact your product vendor for assistance.