Everyone knows what a menu is, the question is how can you make them in VB?
Well, it turns out to be very simple. VB has a built-in menu
editor that you will use and it's pretty much a no-brainer. The only time
menus should give you any trouble is when you want to do some of the more
sophisticated tasks such as adding menus on the fly or such as providing
popup menus. Considering that virtually every application I've ever written
makes use of menus, I was glad to see that Microsoft made it so easy to do.
Menus Are Controls!
You already have been exposed to menus. The most well known example being
the File/Open menus used by most Windows programs for opening a file.
What you may not know is that each
of the menu selections File and Open are independent controls which VB can
create for you using the menu editor. We'll get to that in just a second.
The concept that a menu selection is really a control is a very valuable
piece of information because as you will see, the menu
controls support properties and events, just like any other controls you're
used to seeing. What this means is that you can use the experience you have
in using controls to help understand menu operation.
What menus don't support are methods. If you didn't read
through my control summary spreadsheet you might not have noticed it, but
controls may or may not implement all three of the categories -
events, methods, and properities. There's no rule that says you have to
support them all, and in some cases it's just not necessary. Menu controls
are like that. You'll see that properties and events are all you need.
Before we get into the menu editor, in which you can set properites of a
menu control, let's look at the complete list of menu control properties. It's
not very long:
- Caption - the visible text you see
- Name - the name used in code to refer to the menu control
- Checked - determines whether a small check mark is displayed to the left of the menu control
- Visible - determines whether a menu control can be seen
- Enabled - if FALSE, the text is grayed out and cannot be selected
- Index - used only when the menu control is part of a control array
- Shortcut - a key sequence that will invoke the menu
- HelpContextID - determines which topic in the help file will be displayed
- NegotiatePosition - works in conjunction with OLE embedment to determine which menu controls are displayed
- WindowList - determines whether a menu control maintains a list of the current MDI child windows
The event list for Menus controls is very short because Menus support only
one event, the click event:
The bottom line for using menus is that you use the Menu Editor to create
the menu structure and to set the properties for each menu. Then
you add code to each Click event to perform whatever function you
choose in response to a user selection of the menu items.
- Click - occurs when a menu item is selected
Here's the Menu Editor window:
As you can see, the editor has two general sections. In the top half, you
set the properties (you saw a complete list of the properties above). In the
bottom half you create the heirarchical strucure of the menu.
Remember that menus are only associated with a form. No other control
has a menu. VB provides the built-in ability to manage the display of all
of the menu items. You only have to create the structure and let VB handle
it from that point on.
Also note that each and every form in your application can have it's own
menu. The menus can be identical (same properties) or they may be different.
It's entirely up to you.
Now. let's talk about each of the properties and see
if there's some guidance on what to use for the properities.
Simply use the shortest name you can. Users hate long captions because
they take up to much space on the screen and reading them slows down
using the menu. Also,
try to use a caption that doesn't have the same first letter as any other
menu caption. This will allow you to use the first letter of the control
caption as the shortcut - it makes it much easier for the user to remember!
While it can be anything, remember that the menu event will bear this name.
I always use a name that starts with mnu so that I can recognize the event
procedure as belonging to a menu control. For example, the File menu caption
usually is associated with a menu name of mnuFile.
Menu items are either checked, or not. You can check it from within the
menu editor or by using code. For example, this code will cause a menu
item to be displayed with a small checkmark to it's left:
mnuFileOpen.checked = TRUE
If you want to prevent a user from having access to a menu item, simply set
the visible property to FALSE. This will keep the user from even knowing that
the menu item ever existed.
mnuFileOpen.visible = FALSE
To allow the user to see the menu, but not to select it, set the enabled
property to FALSE:
mnuFileOpen.enabled = FALSE
If you give a menu (or any control) a non-zero index value, that makes it
a member of a control array. Control arrays are covered elsewhere in the
tutorial, but the bottom line is that you can use the Load function to
add new menu items at run time, but only if there is a menu control
array created during design time. This isn't something you'll do a lot of,
but at least be aware that it is possible. On the other hand, there are lots
of times where non-menu control arrays are very useful, so keep the idea of
control arrays in your mind and we'll talk about how to apply them elsewhere
in the tutorial.
Most users want to be able to invoke a menu item from the keyboard. This
is the property that defines the shortcut key strokes. When a shortcut is
defined, you can invoke the menu item from the keyboard, no matter how
deep in the menu structure the item is that you are calling.
Like any control, this allows you to refer to a specific topic in the
application's HELP file. Pressing F1 while the menu item is highlighted
will call up this topic. This is a useful technique, but mostly applies
to HELP files you've written yourself. It speeds up how quickly a user can
drill through the HELP file to get to information about a menu item. In my
own applications, I seldom use this feature. Lazy perhaps, but it's not
that terrific a feature to warrant maintaining the synchronization between
an application and a continously changing HELP file.
When you embed an OLE object which has it's own menus you have to give
instructions on how to blend the form's menu and that of the embedded object.
Because I don't depend on my users having specific OLE-enabled applications
(such as Word, Excel, or others) I rarely use this feature. When you need
it, it's great, I just don't expect most programmers to need it.
Only for use in MDI applications, where you have multiple MDI windows open
at one time. This is another feature which is really great if you need it,
but in my own applications I rarely need it. In this case, even though I
don't use it much myself, you might want to give MDI windows a second look
because of the convenience they offer to users. Microsoft changed version
6.0 of VB to default to MDI windows in its IDE because of user inputs which
supported the change. I still set my own IDE to the single window interface
but you may find your own tastes running differently.
Other Menus Tips
To end this section of the tutorial, here's a few areas where special
handling of menus might make your program more user friendly.
Previously Opened Files
You've seen applications which provide a list under the File menu, of files
which have been previously opened. There are two basic ways to do this, either
by dynamically adding controls (remember my comment about control arrays?)
or by creating the list during design and simply setting the caption and
visible properties to reflect the most recently used file names.
When I write applications, I use Registry Settings to store the most recent
file names and then set caption/visible properties of 4 or 5 pre-built
Feature-Activated Menu Items
One of the user-friendly techniques you should put in your applications is
the practice of setting the visible property of menus to FALSE if the user
is not allowed to use the menu. For example, if a program allows a user to
make a selection of objects in the window then you might make visible a menu
item to delete the selected items. However, if there are no items selected,
then you should set the visible property of the delete menu item to FALSE
because the user has nothing to delete.
The alternative is to set the enabled property of the unusable menu items
to FALSE. The user can still see the menu item but it will be grayed out
and will not work correctly.
Unless you have specific reasons to keep it visible, my preference is to
set the visible properties to FALSE so as not to clutter up a user's screen.
You should use this capability of VB as much as possible. PopUp menus
are a means of providing a user with context sensitive menus - which are
menus that provide only the options which are likely to be used according
to where on the screen the mouse is located. Typically, the popup menu is
activated by using the right mouse.
First of all, any menu that is to be a PopUp menu must not be visible. Once
it's visible setting is set to FALSE you can use it as a PopUp menu. Plus,
you can have multiple PopUp menus on the same form.
Secondly, the invisible menu must have sub-menus. You call the invisible
menu and it's visible sub-menus are displayed.
Here's the basic code for a PopUp menu. This example assumes that you have
a menu called "mnuTestPopUp" whose visible property is set to FALSE. Put this
code in the MouseUp event of a form (form1 in this example).
If Button = 2 then
You can put this code in the MouseUp event of any control, but the line of
code must read "form1.PopupMenu" because only forms have menus.
When you create a program, the IDE allows you to define the .hlp file which
is displayed by WinHelp when you press F1. But be sure to include a Help
menu on the top of your form. Users will expect it. In that menu, you
should include at least two selections - "Contents" and "About". The
contents should go to the contents section of the help file, but the about
selection is normally used to call up a small window which gives version
and author information about the program.
Also, put the Help menu at the far right of the menu selections. Your users
are used to seeing it there and they will expect to find it in the same place
as all other Windows programs that they use.
You'll notice that I have used the phrase "users will expect it" several
times. Remember that as a programmer you want users to feel comfortable
using you program and you don't want to force them to use a non-standard
interface unless there is a clear advantage to doing so. Bottom line is
that for your users' sakes, you should stick with Windows standards whenever
So, there you have it. If you have any trouble with menus or needs some
more examples, the VB HELP file has some pretty good code examples to help