Page History
...
- Unless you are committed to CUA 1989, and are prepared to possibly alter the way you design midrange application systems, you will find that you are generating large amounts of RDML code to "fight against" that natural flow and architecture built into the LANSA implementation of action bars (in support of CUA 1989).
- Not all types of applications are suitable for action bar implementations. Refer to the CUA 1989 guidelines following for more details in assisting you to make this decision.
- Action bars require more frequent, but usually more compact, screen panel interactions. They may not be suitable for use over slow communications lines. However, in some instances, the compact nature of action bars and pull downs may actually be more suitable on a slow communications line than traditional menu driven applications. There is only one way to find out the suitability of an action bar implementation on a communications link: implement a small prototype application and try it out.
- Never attempt to design a full scale action bar system at your first attempt. Always attempt a small prototype system first to gain the required design and programming experience and to judge the suitability of the application for an action bar approach.
| Anchor | ||||
|---|---|---|---|---|
|
1. Create a process of type ACT/BAR, and include into it one RDML function called PROTO, like this: DISPLAY FIELDS
DISPLAY FIELDS(#AB$OPT #PD$OPT) IDENTIFY(*DESC)
PANEL_ID(*NONE)
2. After keying in the RDML command, compile function PROTO to assemble the prototype action bar. This dummy function shows the values of the special AB$OPT and PD$OPT fields from the action bar and pull down option chosen.
...
10.14.2 Applications Most Suitable for Action Bar Implementation