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:

• Click - occurs when a menu item is selected

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.

Menu Editor

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 hierarchical structure 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 properties.

• Caption
  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!
• Name
  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.
• Checked
  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 check mark to it's left:

mnuFileOpen.checked = TRUE

• Visible
  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

• Enabled
  To allow the user to see the menu, but not to select it, set the enabled property to FALSE:

mnuFileOpen.enabled = FALSE

• Index
  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.
• Shortcut
  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.
• HelpContextID
  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.
• NegotiatePosition
  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.
• WindowList
  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 menu items.

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.

PopUp Menus

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  

form1.PopupMenu "mnuTestPopUp"

End If

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.

HELP Menu

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 you can!

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 you along.