In order for this site to work correctly, and for us to improve the site, we need to store a small file (called a cookie) on your computer.
By continuing to use this website, you agree to our cookies and privacy policy.
  
Home page Home page Home page Home page
Pixel
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel
Pixel

Menus and Menu Drivers

When developing end user applications it is frequently the case that the menu drivers provided by the system (AREV and PULLDOWN) do not provide all of the functionality required. Extra security might be wished for, or to aid learning curves the user might specify a Novell style menu structure. Alternatively, access may be required to some of the more esoteric aspects of the provided menu driver's functionality. This article explores the system labelled common and subroutines associated with menus to assist in the development of more generic driver routines.

/%MENUSTYLE%/ Winus_name

The labelled common area %MENUSTYLE% contains the name of the routine currently being used as the default menu driver. This will normally be AREV_WINUS or PULLDOWN_WINUS.

/LCMENUS/ Menu_List, Menu_Pos

The labelled common area LCMENUS is used to store generic information about the position of the current option within menus (for the "Stickum" feature). The way in which it is treated differs from menu driver to menu driver so use %MENUSTYLE% to get the current menu style before playing with these variables.

     Menu_List
     As menus are accessed their names are loaded into an @FM delimited
     array of menu names. Each new menu name is inserted at the beginning of
     the array. When using the PULLDOWN menu style it can be seen that when
     choosing a menu selection with a single option, a "pseudo" menu
     appears, showing the single option and an Escape to Exit message. As
     this is not a proper menu option a dummy variable called
     %%CUAWINUS_TEMP%% is inserted into Menu_List and is used for all such
     accesses.

     Menu_Pos
     An @FM delimited list of values associated with Menu_List. Each field
     has three values, being used slightly differently in different menu
     drivers.

          AREV      < 0, 1 >  Amount of columns across menu (origin = 0 -
                              i.e. if the value is 4 this is the 5th column)
                    < 0, 2 >  Row down menu (origin = 0 - i.e. if the value
                              is 3 this is the 3rd row)
                    < 0, 3 >  Number of last option accessed

          PULLDOWN  < 0, 1 >  Not Used
                    < 0, 2 >  Not Used
                    < 0, 3 >  Number of last option accessed

MENU.BUFFER(Menu_Name, Flag)

The system uses the function MENU.BUFFER to read menus from disk and to update the LCMENU area by including the menu name in Menu_List and the initial coordinates in Menu_Pos. It may be used in customised menu drivers. To use, declare as a function and pass the name of the menu to load and a flag variable which will return the position of the menu within Menu_List. If the menu is being loaded for the first time the position flag will be set to 1, otherwise it will return a pointer into the arrays. This could be used by the developer to position the cursor at the appropriate "Stickum" point. EG


0001         common /LCMENUS/ MENU_LIST, MENU_POS
0002         declare function MENU.BUFFER
0003         MENU_REC = menu.buffer("TOOLS", FLAG)
0004         OPTION_TO_START_AT = MENU_POS< FLAG, 3>
0005         gosub DISPLAY_MENU

Customised Menu Drivers

A point that no longer seems to be documented is that it is possible to replace the default system menu driver with one written by the developer. This is because the menu driver WINUS simply acts as a despatching program to call the appropriate menu driver nominated in the environment. Any replacement menu drivers written need to be suffixed with "_WINUS" E.G. NOVELL_WINUS. This routine must accept 5 parameters as defined in UTILITY.DOC, WINUS in the old (1.x) Utility Subdirectory. Note though that if the customised menu driver is made the default, the five parameters do not need to be used as described. However if you ever intend to allow your menu driver to exit once it has been entered (rather than just refusing to allow escape from a top level menu) ensure that when exiting at the top level the code and command portions are nulled down or WINUS will treat them as catalyst code and commands and try to execute them.

To make the customised menu driver the system menu driver, it is necessary to make the system "Menu Style" (as it is referred to in the environment window) equal to the name of the menu driver minus the _WINUS. Thus if your driver were called NOVELL_WINUS you would set the menu style equal to NOVELL. Unfortunately you cannot do this using the environment window as it edit checks for AREV or PULLDOWN. Consequently you can either PAINT COMMANDS MENU.ENV and amend the template to permit the use of your driver, or put the name of your driver (minus the _WINUS) into the environment record for the user in field 82.

N.B. If the menu is defined as "unanchored", the customised menu driver must return the code and command to the calling routine and not attempt to process it. Failure to comply with this directive will mean that routines like PAINT will fail to work correctly.

(Volume 3, Issue 3, Pages 13,14)
Pixel
Pixel Footer R1 C1 Pixel
Pixel
Pixel
Pixel