At last we reach the 32-bit extended menu template.
Introduced in Windows 95, this remains the
most advanced menu template format through Windows Vista.
As you might expect, the 32-bit extended menu template is
just a 32-bit version of the
16-bit extended menu template,
so if you've been following along, you should find no real
surprises here;
all the pieces have been telegraphed far in advance.
The header remains the same:
struct MENUHEADER32 {
WORD wVersion;
WORD cbHeaderSize;
BYTE rgbExtra[cbHeaderSize-4];
};
The differences here from the 32-bit classic menu template header
are analogous to the changes between the 16-bit classic menu template
and the 16-bit extended menu template.
The wVersion is set to one for extended templates,
and the cbHeaderSize includes the wVersion
and cbHeaderSize fields themselves,
so the number of extra bytes is four less than the value specified
in cbHeaderSize.
There is one additional constraint:
The cbHeaderSize must be a multiple of four
because extended menu item templates must be aligned on DWORD
boundaries.
But as with 32-bit classic templates, the
cbHeaderSize must be four in order to avoid a bug
in the Windows 95 family of operating systems.
After the header comes the menu itself,
and like the 16-bit extended menu template,
there is a prefix structure that comes before the items
and which serves the same purpose as in the 16-bit extended menu template:
struct MENUPREFIX32 {
DWORD dwContextHelpID;
};
The list of menu items is basically the same as the 16-bit version,
just with some expanded fields.
struct MENUITEMEX32 {
DWORD dwType;
DWORD dwState;
DWORD dwID;
WORD wFlags;
WCHAR szText[]; // null terminated UNICODE string
};
As we saw before when we studied the 16-bit extended menu template,
the big difference between classic and extended menu items
is that classic menu items were designed for the
InsertMenu function,
whereas extended menu items were designed for the
InsertMenuItem function.
The dwType, dwState, and
dwID members correspond to
the fType, fState, and
wID
members of the MENUITEMINFO structure,
and the the szText goes into the
dwItemData if the item requires a string.
One additional quirk of 32-bit extended menu item templates
which the 16-bit version does not have is that 32-bit
extended menu item templates must begin on a 32-bit boundary;
therefore, you must insert a WORD of padding
after the menu text if the text is an odd number of characters
long.
(Fourteen bytes of the fixed-length part of the MENUITEMEX32
plus an odd number of WCHARs
plus the null terminator WCHAR leaves a value that is
2 mod 4; therefore, you need an additional WORD
to return to a DWORD boundary.)
The wFlags field has the same values as in the
16-bit extended menu item templates; the high byte is always zero.
And, as before, if the bottom bit is set, then the menu item describes
a pop-up submenu, which is inserted directly after
the extended menu item template.
That's all there is to it.
Let's see how our example menu resource looks when converted
to a 32-bit extended menu template:
1 MENUEX 1000
BEGIN
POPUP "&File", 200,,, 1001
BEGIN
MENUITEM "&Open\tCtrl+O", 100
MENUITEM "", -1, MFT_SEPARATOR
MENUITEM "&Exit\tAlt+X", 101
END
POPUP "&View", 201,,, 1002
BEGIN
MENUITEM "&Status Bar", 102,, MFS_CHECKED
END
END
First comes the header, whose contents are fixed:
0000 01 00 // wVersion = 1
0002 04 00 // cbHeaderSize = 4
Before the list of extended menu item templates, we have the
context help ID:
0004 E8 03 00 00 // dwContextHelpID = 1000
Since our first menu item is a pop-up submenu,
the wFlags will have the bottom bit set:
0008 00 00 00 00 // dwType = MFT_STRING
000C 00 00 00 00 // dwState = 0
0010 C8 00 00 00 // wID = 200
0014 01 00 // wFlags = "pop-up submenu"
0016 26 00 46 00 69 00 6C 00 65 00 00 00
// "&File" + null terminator
0022 00 00 // Padding to restore alignment
Notice the two bytes of padding so that we return to
DWORD alignment.
The wFlags promised a pop-up submenu, so here it is.
0024 E9 03 00 00 // dwContextHelpID = 1001
// First item
0028 00 00 00 00 // dwType = MFT_STRING
002C 00 00 00 00 // dwState = 0
0030 64 00 00 00 // dwID = 100
0034 00 00 // wFlags = 0
0036 26 00 4F 00 70 00 65 00 6E 00 09 00
43 00 74 00 72 00 6C 00 2B 00 4F 00 00 00
// "&Open\tCtrl+O" + null terminator
// Second item
0050 00 08 00 00 // dwType = MFT_SEPARATOR
0054 00 00 00 00 // dwState = 0
0058 FF FF FF FF // dwID = -1
005C 00 00 // wFlags = 0
005E 00 00 // ""
// Third (final) item
0060 00 00 00 00 // dwType = MFT_STRING
0064 00 00 00 00 // dwState = 0
0068 65 00 00 00 // dwID = 101
006C 80 00 // wFlags = "this is the last menu item"
0070 26 00 45 00 78 00 69 00 74 00 09 00
41 00 6C 00 74 00 2B 00 58 00 00 00
// "&Exit\tAlt+X" + null terminator
0086 00 00 // Padding to restore alignment
When we see the "end" marker, we pop one level back to the main menu.
0088 00 00 00 00 // dwType = MFT_STRING
008C 00 00 00 00 // dwState = 0
0090 C9 00 00 00 // dwID = 201
0094 81 00 // wFlags = "pop-up submenu" |
// "this is the last menu item"
0096 26 00 56 00 69 00 65 00 77 00 00 00
// "&View" + null terminator
00A2 00 00 // Padding to restore alignment
The set bottom bit in the wFlags indicates
that another pop-up submenu is coming,
and the "end" marker means that once the submenu is finished,
we are done.
00A4 EA 03 00 00 // dwContextHelpID = 1002
00A8 00 00 00 00 // dwType = MFT_STRING
00AC 08 00 00 00 // dwState = MFS_CHECKED
00B0 66 00 00 00 // dwID = 102
00B4 80 00 // wFlags = "this is the last menu item"
00B6 26 00 53 00 74 00 61 00 74 00 75 00
73 00 20 00 42 00 61 00 72 00 00 00
// "&Status Bar" + null terminator
00CE 00 00 // Padding to restore alignment
Since the pop-up submenu has only one item, the first item is also
the last.
That's it for the evolution of menu templates,
starting from a series of calls to the ANSI version of
InsertMenu
to a series of calls to the Unicode version of
InsertMenuItem.
Menu templates get much less attention than dialog templates,
but if you wanted to know how they work, well, there you have it.
