So far we have three example action bar applications to "Select", "Display" and "Change" our "object".
The next step would be to arrange them into an action bar, or to plug them into a previously set up prototype action bar.
Both these subjects have been described in some detail in earlier sections.
Once this setup has been done, the action bar can be used.
However, there is one final step that might be considered to improve the performance of the action bar application.
If this example was run as is, the user would jump between 3 separate compiled RDML functions, and each jump would involve the opening and closing of files, deactivating and reactivating of programs, etc.
This overhead may be small and acceptable in most applications, but to maximize performance you can combine multiple action bar processing programs into one RDML function.
The secret to this performance trick is that the action bar control logic has some "intelligence" built in to it.
Normally, if a user switches to the action bar and selects another pulldown choice / function, the current function is terminated and the new one is started. This is what causes the overhead.
However, if the selected pull down choice is actually going to use the same function as the one that is currently active, the action bar logic just "restarts" the current function from the beginning.
No close/open or deactivate/reactivate logic is performed.
It should now be apparent why the PD$OPT and AB$OPT values are defined in the action bar control table. They are what allow a "combined" action bar function to work out what action it has to perform.
The AB$OPT value indicates the action bar option that was selected by the user.
The PD$OPT value indicates what pull down choice was selected by the user.
If our 3 example pull down choices "Select", "Display" and "Change" has PD$OPT values of SEL, DIS and CHG respectively, then the obvious mainline for our combined RDML function would look something like this:
EXCHANGE FIELDS(#OBJECTKEY) OPTION(*ALWAYS)
CASE OF_FIELD(#PD$OPT)
WHEN VALUE_IS('= SEL')
EXECUTE SUBROUTINE(SEL_OBJECT)
WHEN VALUE_IS('= DIS')
EXECUTE SUBROUTINE(DIS_OBJECT)
WHEN VALUE_IS('= CHG')
EXECUTE SUBROUTINE(CHG_OBJECT)
ENDCASE
All that is required now is to combine our previous example functions into subroutines of this mainline like this:
SUBROUTINE NAME(SEL_OBJECT)
<< "Select" routine as per previous example >>
ENDROUTINE
SUBROUTINE NAME(DIS_OBJECT)
<< "Display" routine as per previous example >>
ENDROUTINE
SUBROUTINE NAME(CHG_OBJECT)
<< "Change" routine as per previous example >>
ENDROUTINE
Next we compile this new "combined" function and finally change the action bar control table to indicate that all the pull down choices should invoke this new "combined" function.
The restart logic is very simple.
When a DISPLAY or REQUEST command is logically terminated by the user from the action bar, and the new selected function is the same as the one that is currently active, control passes back to the first executable command in the program again (ie: the CASE command).
Lists are not cleared, variables are not re-initialized, etc.
It is just as if you executed a GOTO command to the start of the program.
Finally a word of warning: even though this function now contains 3 combined functions, their logical "separation" must be maintained.
Do not use the fact that these routines are now combined to start introducing interdependencies and cross executions between them.
Their independence must be maintained.
