NORMALMENUITEM structure
Applies to: desktop apps only
Contains information about each item in a menu resource that does not open a menu or a submenu. The structure definition provided here is for explanation only; it is not present in any standard header file.
Syntax
typedef struct {
WORD resInfo;
szOrOrd menuText;
} NORMALMENUITEM;
Members
- resInfo
-
Type: WORD
-
The type of menu item. This member can be one of the following values.
- menuText
-
Type: szOrOrd
-
A null-terminated Unicode string that contains the text for this menu item. There is no fixed limit on the size of this string.
Remarks
There is one NORMALMENUITEM structure for each menu item that does not open a menu or a submenu. Indicate the last menu item on a menu by setting the resInfo member to MFR_END.
A menu separator is a special type of menu item that is inactive but appears as a dividing bar between two active menu items. Indicate a menu separator by leaving the menuText member empty.
Requirements
|
Minimum supported client | Windows 2000 Professional |
|---|---|
|
Minimum supported server | Windows 2000 Server |
See also
- Reference
- MENUHEADER
- MENUITEMINFO
- POPUPMENUITEM
- Conceptual
- Resources
Send comments about this topic to Microsoft
Build date: 2/3/2012
#include <WinUser.h>
...
struct NormalMenuItem {
WORD fItemFlags &= (!MF_POPUP) /* |= MF_END */; //or resInfo, if you really want to call it that now
WORD wMenuID;
WCHAR szItemText[]; // not szOrOrd!
Legacy menus have no concept of localized STRINGTABLE index lookups, which is the use an Ord value would make sense
for being there. I don't believe that's been implemented yet even for MENUEX items. It should be, but the current MUI
scheme of one .MUI.DLL per language makes that impractical anyways. The definition was never extended to reference
BITMAPS either, or RC_DATA for MF_OWNERDRAW items, localized or not.
/* WORD Pad; */ // if needed for DWORD alignment of contiguously following resource entry
} NORMALMENUITEM;
What MF_ flags are legitimate values for fItemFlags inclusion, when specified in an RC file, so that LoadMenu() won't crash should be rosterized, with their values as defined in <WinUser.h>.
MF_END should be included in <WinUser.h>, as it has a use in templates for applications using LoadMenuIndirect().
The description of MF_END usage is erroneous anyways. The value gets ORed into fItemFlags of the last entry for that sub-menu level, not set to it.
It's also missing an explicit definition for SEPARATOR entries. Are they:
struct SeparatorlMenuItem {
WORD fItemFlags |= MF_SEPARATOR /* |= MF_END */;
WORD wMenuID;
WCHAR szItemText = '\0';
/* WORD Pad; */ // if needed for DWORD alignment
} SEPARATORMENUITEM;
or
struct SeparatorMenuItem {
WORD fItemFlags |= MF_SEPARATOR /* |= MF_END */;
WORD wMenuID;
/* WORD Pad; */ // if needed for DWORD alignment
} SEPARATORMENUITEM;
Also, for POPUPMENUITEM, the MFT/MFS based flags and fields are only appropriate in MENUEX resources, not legacy MENU field definitions. It should be changed back to:
struct PopupMenuItem {
WORD fItemFlags |= MF_POPUP /* |= MF_END */; // or resInfo
WCHAR szItemText[];
/* WORD Pad; */ // if needed for DWORD alignment
} POPUPMENUITEM;
and fix the text there to indicate proper MF_END usage.
Frankly, I've always wondered why the sections describing RC and MC, and the text files they use, aren't also under Windows User Interface\Resources. Both sections are in need of overhauling, with this item being a small sample of the types of errors that need editing, so they may as well be merged.
- 11/5/2010
- Mr Ziggy
