16.3MERGED MENUS

By definition, an MDI application permits multiple windows to be displayed. Each child window may be the same or different, and each may display different information about one or more objects. It would be nice if the menu items for the application could be customized depending on which child window is displayed. Exactly how to do this is the subject of this section.

As an example, consider a car-buying application that permits users to search for, display, and purchase used cars. As an MDI application, this might display a photograph of the car in one window, standard features and warranty information in another window, and optional packages and pricing information in a third window. Clearly the set of menus and the contents of each menu should differ depending on which style window is currently active. For instance, menus for the photograph window might permit different colors to be viewed or different parts of the vehicle to be shown. These concepts make no sense for the other windows, and should not be accessible when these windows are active.

While our application is not quite so ambitious, we do have the problem of our File menu, since both the ParentForm and the MainForm class contain this item. Once we make the two File menus merge, we also have to deal with the contents of these menus, to ensure the items appear in an appropriate order.

The Menu class provides a MergeMenu method for merging two menus together. This method accepts a Menu object and merges it with the calling Menu object. The MenuItem class provides additional overrides of this method to merge MenuItem objects and to copy a menu item so that it may be merged with other menus. This latter method has the advantage of not affecting the existing MenuItem object.

In MDI applications, an MDI container form automatically merges the menu for the active child form with the MainMenu object stored in its Menu property. The Form.MergedMenu property contains the result of this merge, and can be used to access or modify the merged menu directly. The Form.Menu property always contains the original menu assigned to the form.

Since this merging occurs automatically for MDI applications, this section will focus on how menus are merged together, and make the appropriate changes in our MDI application to merge the two File menus together. First we will discuss the various ways to merge two menus, followed by the mechanism for establishing the order of merged menu items.

16.3.1ASSIGNING MERGE TYPES

As mentioned at the start of this chapter, the MenuItem class contains two properties

that control exactly how two menus are merged together. This section will discuss the MergeType property that controls how the menus are merged. Later we will look at the MergeOrder property that controls the final position of a merged item.

The MergeType property gets or sets a MenuMerge enumeration value specifying how this menu should be merged with other menus. An overview of this enumeration appears in .NET Table 16.1. The default setting for the MergeType property is MenuMerge.Add. This default adds each item separately, and is the cause of the two File menus in our current application.

.NET Table 16.1 MenuMerge enumeration

The MenuMerge enumeration specifies various types of behavior for a MenuItem object when it is merged with another menu. This enumeration is used by the MergeType property in the MenuItem class, and is part of the System.Windows.Forms namespace.

This explains why our existing application has two File menus. Since the MergeType property defaults to Add, the menus are simply added to the collection separately.

We can fix this by modifying the MergeType property for these menus.

Set the version number of the MyPhotos application to 16.3.

MERGE THE PARENT AND CHILD FILE MENUS

Compile and run the application, and open a client form in the parent window to see the merged menu as shown in the table. The two menus are merged, but their contents

are not exactly in an acceptable order. This is because each of the MenuItem objects within their respective File menus use the default MergeType property, which is Add. As a result, each menu item is simply added to the end of the list. The items from the parent form appear first, followed by the items from the child form.

We can fix this, of course, but first a brief aside.

TRY IT! Modify the MergeType property for either File menu so that one menu uses the MergeItems member value and the other the Add value. Run the application to verify that the menus no longer merge.

Also rename the File menu in the ParentForm class to use the name “Fickle.” Run the application and see which name is shown in the application. You will find that the name in the MDI child is preferred over the name in the parent. This is a consequence of how the menus are merged, and can be utilized to rename a menu in the parent form when a specific kind of child is displayed.

Back in our application, we have two problems with the merged File menu. The first is that we have two versions of the New and Exit menus, and the second is that the order of the merged menu is a bit of a mess.

We will address these two problems together as part of a discussion on the MergeOrder property.

16.3.2ASSIGNING MERGE ORDER

So far we have merged our two File menus into a single menu. The next step is to clean up the contents of this menu. This involves setting the appropriate MergeType for each menu, and using the MergeOrder property to establish the order of these items within the merged menu. The MergeOrder property contains the zero-based position where the menu should appear within the merged menu. If multiple items are assigned the same order, they appear one after another in the merged menu. This

is the case in our existing code, where all menus in the File menu use the default MergeOrder value of zero.

Before we start making changes to our existing menus, let’s step back and consider what a reasonable File menu should contain for our MDI application. Such a menu is described by the following table, which shows the menu name, its position, a short description, and some implementation notes.

Contents of the merged File menu in our MDI application

This details how the merged menu should look. There is still the question of the menu structure in the ParentForm and MainForm classes. Based on the previous table, we can establish how the File menu should appear for each Form class. The following table details the contents of each menu, and describes its behavior in the merged menu object.

Individual File menu for our MDI parent and child classes

We are now ready to update our menus based on these tables. Our first change will simply update the menus so that they appear as described within the application.