FoxTalk - dFPUG-Portal

FoxTalk
Solutions for Microsoft® FoxPro® and Visual FoxPro® Developers
Menus – A Data-
Driven Approach
Chad J. Lemmer
Like many other Visual FoxPro developers, I long for the day
when Microsoft updates the Menu Designer to be objectoriented.
Some developers have gone to great lengths and
have come up with excellent ways to make the current Menu
Designer object-oriented. As an alternative to object-oriented
menus, Chad Lemmer presents another approach—a tabledriven
menu system.
RECENTLY, I was working on an application where I
needed a menu system that was easy to use
and maintain, and that also had built-in security. If
a user didn’t have access to a certain task in the system, I
didn’t want the option to even show up on the menu.
“Out of sight, out of mind.” Let’s face it, who likes
looking at an interesting menu option, only to select it and
receive a hostile message informing them that they’ve
done something terribly wrong. If the user doesn’t belong
there, then I don’t like giving them the option to go there.
In all of my experiences using FoxPro, there’s one
thing that I’ve learned—to make things table-driven
wherever possible. It might take a little more work up
front to get the ball rolling, but the extra time and effort is
almost always gained back if changes need to be made
later. My initial idea was to create a menu class that
would use the DEFINE PAD, DEFINE POPUP, and
DEFINE BAR commands to build a standard menu
driven by a menu table and a user access table. After
looking into the DEFINE commands a bit further, I
concluded that the class code could get pretty hairy. In
addition, the system was going to be used in a
manufacturing environment with touch screens, and if
you’ve ever used a touch screen, you know that selecting
items from a standard Windows menu bar is a nuisance
because the text is too small.
After a few more brainstorming sessions, I decided
to create a menu form that would be table-driven to
This is an exclusive supplement for
FoxTalk subscribers. For more
information about FoxTalk, call us at
1-800-788-1900 or visit our Web site
at www.pinnaclepublishing.com/ft.
Extended Article
simplify the adding, modifying, and removing of
menu items. The menu class excludes items by referring
to a user security table that stores the menu items to
which a user has access. The menu class also takes
care of the touch screen problem because the menu
form would use a ListBox to display the menu items
with a font big enough for even Sampson’s
index finger!
How it works
The clMenu class consists of a form with a ListBox to
display menu options, along with an EditBox to display
a more detailed description of the menu option. To
execute a menu item, the user selects it from the ListBox
and clicks on the “Run” button or presses the Enter key
(see Figure 1).
http://www.pinnaclepublishing.com/ft FoxTalk Extended Article: October 2000
1
6.0
Figure 1. An example of a menu form created by the
clMenu class.

The clSysMenu table
The clSysMenu table is used by the clMenu class to
populate the ListBox with menu items. Table 1 shows the
structure of the clSysMenu.
Each record in the clSysMenu table defines either
another menu to display or a menu item to add to the
ListBox. To instantiate another menu, you’d populate the
cRunMenu field with a value from the cModuleID field that
represents the menu you want to show. This setup provides
an unlimited number of submenus. Each menu in the table
must have a header record that specifies various menu
properties such as the caption, icon, and color of the menu
name. To create a menu header record, set the cMenuID
field equal to the cModuleID field. When the clMenu class
instantiates, it SEEKs the menu header record and sets
the menu various form properties accordingly.
To execute a FoxPro program, application, or form,
you’d populate the cPath and cRunFile fields with the path
and filename to execute, respectively. The cMenuID field
stores a unique key to each menu item. The unique keys are
used in conjunction with a clUser table’s mAllowAcc field
that defines the menu items to which a user has access.
Table 1. The clSysMenu structure.
Field Description
cModuldID Used to group menu items together. All items that
belong to a menu have the same value in this field.
cMenuID A unique menu item ID used for security and to
uniquely identify each menu item.
nOrder Specifies the order in which the menu items
should appear.
cMenuName The name of the menu or menu item to display in
the ListBox.
cRunMenu If specified, displays the specified submenu.
cIconFile The file name for the icon to display on the menu
form’s caption bar. Used in header records only.
cPath Specifies the path for the file to execute in the
cRunFile field or the icon specified in the
cIconFile field.
cRunFile If specified, the file in this field will be executed
when the menu item is selected.
cParms Additional parameters to pass to the file specified
in the cRunFile field.
mComment A longer description of the menu item to be
displayed on the menu form class.
nRed Passed to the RGB() function to allow different
menu captions to have different colors. Used in
header records only.
nGreen Passed to the RGB() function to allow different
menu captions to have different colors. Used in
header records only.
nBlue Passed to the RGB() function to allow different
menu captions to have different colors. Used in
header records only
The clUser table
The clUser table contains one record per user and has a
memo field that contains a list of values from the
clSysMenu.cMenuID field to which the user has access.
Table 2 shows the structure for the clUser.
Table 2. The clUser structure.
Field Description
cLoginName The name of the current user that’s logged into
the application.
mAllowAcc A list of values from the clSysMenu.cMenuID field
that the user has access to.
lAutoClose If set to .T., the previous menu will close
automatically when a new menu is created,
except for the main menu.
When the clMenu class spins through the clSysMenu
table to add items to the ListBox, it only adds the menu
item if the item’s cMenuID is present in the clUser
security table record. Another field, lAutoClose, tells the
clMenu class to close the previous menu after running a
submenu, unless they’re calling a submenu from the main
menu. The main menu will always stay open.
The clMenu class
The clMenu class spins through the records in the
clSysMenu table to populate the ListBox with menu
options that the user has access to. The main menu for
your application can be created by using the NewObject()
function, passing it “MAIN” as the module ID and the
user name of the user logged into the application. Once
the main menu is instantiated, the clMenu class takes over
from there. You probably want to add the line
SYSMENU=OFF in your CONFIG.FPW file to remove the
Visual FoxPro system menu from your application. The
following is an example of how to instantiate the main
menu for your application:
public oMainMenu
oMainMenu = NewObject("clMenu", "clMenu", "", ;
"MAIN", lcLoginName)
if type("oMainMenu") = "O" and ;
!isnull(oMainMenu)
oMainMenu.Show
read events
else
wait window "Unable to create main menu."
endif
The ListBox on the clMenu form is populated by a
temporary cursor called curMenu. This increases the
menu’s overall performance because the ListBox only
contains the values it needs—as opposed to using a
filtering technique on the clSysMenu table to eliminate the
menu items that you don’t want the user to see. The
clMenu class accepts the following parameters as shown
in Table 3.
2 FoxTalk Extended Article: October 2000
http://www.pinnaclepublishing.com/ft

Table 3. The clMenu class parameters.
Parameter Description
tcModuleID Specifies which menu items from the clSysMenu
table to retrieve. Records from the clSysMenu table
who’s cModuleID field value matches this
parameter will be included in the ListBox, if the
user has access to it.
tcLoginName The name of the current user logged into
the application.
In order to create multiple instances of the clMenu
class for each submenu that’s produced, I devised a
method called GetNewMenuObject that returns the next
available menu object name. This method spins through
all of the objects in memory whose Name property starts
with “oMenu” and appends a sequential number on the
end of it until it comes up with an object name that isn’t
being used. Notice the code for the GetNewMenuObject
method in the following example:
lparameters tnMenu
local lnI, lcMenu
lnI = 1
lcMenu = "oMenu" + allt(str(lnI))
do while .t.
if type(lcMenu) "O" or isnull(&lcMenu)
exit
else
* If the menu already exists, then show it
* and don't make another copy of it
if &lcMenu..cModuleID = curMenu.cRunMenu
&lcMenu..show
return
endif
lnI = lnI + 1
lcMenu = "oMenu" + allt(str(lnI))
endif
enddo
tnMenu = lnI
return lcMenu
In addition to finding a unique object name for each
menu that’s created, this code also accepts a parameter
(passed by reference) that tells the calling method what
menu number was returned. The calling method uses the
number to control where the new menu appears on the
screen. By taking the menu number, multiplying it by a
constant, and setting the new form’s Left and Top
properties to that value, it gives the menus a cascading
effect. Otherwise, the submenus would appear directly
over the top of the previous menu (see Figure 2). Also, if
the submenu selected by the user already exists as an
object in memory, this method will show the existing
menu instead of instantiating another one. It does this by
comparing the new menu object’s cModuleID property
with the value in the cRunMenu field, as you can see in
the preceding code.
Conclusion
Because the menu class is table-driven, it’s very easy to
make changes to an application’s menu. Most importantly,
it eliminates the need to modify source code and install
system updates when we need to change the menu. Once
the menu option is added and the user is assigned access
to the menu option, it appears in the menu automatically.
The main disadvantage to this approach is that the menu
isn’t a standard Windows menu that most other
applications use. It comes down to the fact that the
“standard way” might not always be the “practical way”
to solve a problem.
A complete working demo of the clMenu class is
included in this month’s Source Code files. Questions,
comments, and new ideas are always welcome! ▲
10LEMMSC.ZIP at www.pinnaclepublishing.com/ft
Chad J. Lemmer is a full-time I.S. programmer/analyst at Wausau Coated
Products in Wausau, WI, specializing in Visual FoxPro application
development. He also develops Visual FoxPro applications for the clients
of his own consulting business. clemmer@dwave.net.
Figure 2. The clMenu class cascades submenus.
http://www.pinnaclepublishing.com/ft FoxTalk Extended Article: October 2000
3