Visual LANSA applications consist of a set of windows (forms). There is no process with related functions as in traditional RDML programs instead you define the first window to appear in the application and then give the user access to the other windows in the application using menus or command buttons.
A well-designed Visual LANSA application will most likely contain fewer windows than a traditional LANSA application which means navigation between parts of the application is less of a concern. You will find that many applications consist of only one main window. This is because the controls, such as grids and tree views, take up little space on the screen while at the same time offering powerful functionality.
When you first start using Visual LANSA you might structure your application in the same way as a traditional LANSA application and provide access to various parts of the system in a menu similar to those used in IBM i green screen applications.
Below is the main menu of the of the LANSA Personnel Demonstration system modelled on the LANSA for the IBM i and Visual LANSA versions. It was created using Visual LANSA command buttons and text labels.
Even though this approach may be familiar to your users, it is not standard for Windows applications nor does it take advantage of the power of graphical user interface elements. It is also very inflexible: the user has to return to the menu every time he wants to perform a different task.
When complex systems are implemented in this way the result is usually several levels of menus with increased navigational overhead.
The other, more common solution is to provide access to functions using Visual LANSA drop-down menus. Menus are the de facto Windows standard for providing access to different functions.
The functionality of the menus is identical to the traditional menu, but there is one major difference: the menu bar contains several menus side by side. This means that you can fit up to about ten menus in one window. The menu bar only contains the menu titles and the user drops down the menu to display the menu options as necessary.
The menu bar in the example above consists of four drop-down menus: Employees, Skills, Departments, and Help. Each menu consists of one or more menu items. A menu item can also contain submenus (indicated by a triangular arrow).
Every menu title can be dropped down with the mouse or from the keyboard using the Alt key and the underlined letter in the title. Once the menu options are shown, the user can again either select them with the mouse or access them using the underlined letter and the Alt key. Commonly used options can also be given a direct shortcut, as in the above example the Find Employee function can be triggered using the Ctrl key and F without dropping down the menu. Creating consistent shortcuts is important because experienced users use the menus from the keyboard.
Notice that with menus much of the workspace of the window is left free because the menus take up very little screen real estate. Therefore it makes sense to add other elements to the window instead of using it simply as an entry point to the application. Typically you would add the most commonly used functions of the application to the start-up window to make it the main window of the application.
An application in which all or most functions are accessed from the main window is easy and efficient to use because all functions are close at hand. (In a traditional IBM i menu driven application the user may have to navigate through several screens to accomplish just one task.)
In the following Visual LANSA example the personnel system consists of a single main window which provides access to all the functions in the system.
This implementation offers the user much more flexibility and easier access to functions than an application centered on a hierarchical menu.
The number of windows in the applications can be kept down because the components used to create the main window take up little screen space and have powerful functionality.
Navigation Structure for Large Applications
In cases where your application consists of several distinct functions, you should consider making them separate applications and then group them into one Windows program folder.
As shown in the following example, the LANSA desktop folder contains a number of separate applications. These applications have their own icons and can be run independently and concurrently.