Creating menus dynamically

[NoCforMe]

Another in the series of how to create Win32 programs without using resource files or the resource editor.

The "standard" way to get a menu into a window in your Win32 program is to set it up in the resource editor, which is fine and dandy if you want to do things this way.

But what if a guy decides he wants to avoid the whole resource-editor thing? Well, it turns out to be really pretty simple to create menus "on the fly" within your code, requiring zero resources other than some text strings.

Here's the recipe, fleshed out in the attached code sample:

1. Create the menu IDs--the numbers that will be used in your WM_COMMAND handler to dispatch to your code when the user chooses items from the menu--and the text that will be shown in the menus.

2. Create the menus using CreateMenu() and CreatePopupMenu(). The former creates the top-level menu (meaning the whole enchilada), while the latter creates each "submenu", like File, Edit, etc. Here we're just creating a single submenu, File.

3. Create each submenu and each menu item using AppendMenu().

4. Finalize and activate the menu, attaching it to your window, using SetMenu().

It's really that simple. I use this all the time.

Code Select Expand

; Define the menu IDs:

$menuNewFile EQU 1000
$menuOpenFile EQU 1001
$menuSaveFile EQU 1002
$menuSaveFileAs EQU 1003
$menuViewExtraFile EQU 1004
$menuPrintSetup EQU 1005
$menuPrint EQU 1006
$menuConfigEdit EQU 1007
$menuToggleSaveIni EQU 1008
$menuExit EQU 1009

; and the item text:

MenuFileStr DB "File", 0
MenuNewStr DB "New", $tab, "Ctrl+N", 0
MenuOpenStr DB "Open ...", $tab, "Ctrl+O", 0
MenuSaveStr DB "Save ...", $tab, "Ctrl+S", 0
MenuSaveAsStr DB "Save as ...", 0
MenuViewExtraStr DB "View &Extra file ...", $tab, "Ctrl+E", 0
MenuPrintSetupStr DB "Print setup ...", 0
MenuPrintStr DB "Print ...", $tab, "Ctrl+P", 0
MenuConfigEditStr DB "Configuration editor ...", 0
MenuToggleSaveIniStr DB "Save program setup on exit", 0
MenuExitStr DB "Exit", 0

; Create the menu & submenus:

LOCAL menuHandle:HMENU, subMenu:HMENU

CALL CreateMenu
MOV menuHandle, EAX
CALL CreatePopupMenu
MOV subMenu, EAX

; Define the menu items:

INVOKE AppendMenu, menuHandle, MF_POPUP or MF_STRING, subMenu1, OFFSET MenuFileStr
INVOKE AppendMenu, subMenu, MF_STRING, $menuNewFile, OFFSET MenuNewStr
INVOKE AppendMenu, subMenu, MF_STRING, $menuOpenFile, OFFSET MenuOpenStr
INVOKE AppendMenu, subMenu, MF_STRING, $menuSaveFile, OFFSET MenuSaveStr
INVOKE AppendMenu, subMenu, MF_STRING, $menuSaveFileAs, OFFSET MenuSaveAsStr
INVOKE AppendMenu, subMenu, MF_SEPARATOR, 0, 0
INVOKE AppendMenu, subMenu, MF_STRING, $menuViewExtraFile, OFFSET MenuViewExtraStr
INVOKE AppendMenu, subMenu, MF_SEPARATOR, 0, 0
INVOKE AppendMenu, subMenu, MF_STRING, $menuPrintSetup, OFFSET MenuPrintSetupStr
INVOKE AppendMenu, subMenu, MF_STRING, $menuPrint, OFFSET MenuPrintStr
INVOKE AppendMenu, subMenu, MF_SEPARATOR, 0, 0
INVOKE AppendMenu, subMenu, MF_STRING, $menuConfigEdit, OFFSET MenuConfigEditStr
INVOKE AppendMenu, subMenu, MF_SEPARATOR, 0, 0
INVOKE AppendMenu, subMenu, MF_STRING or MF_CHECKED, $menuToggleSaveIni, OFFSET MenuToggleSaveIniStr
INVOKE AppendMenu, subMenu, MF_SEPARATOR, 0, 0
INVOKE AppendMenu, subMenu, MF_STRING, $menuExit, OFFSET MenuExitStr

; Bind the menu to its window:

INVOKE SetMenu, hWin, MenuHandle


[zedd151]

Yabbut... that is a lot of code and data, just for the sake of not using a resource based menu. I have used similar methods too, but always fall back to using a resource menu. Especially if there are many sub menus and/or menu items.
There are some things that an .rc file handles more easily and efficiently than doing it in the source file. This being one of them, imho.

[sinsi]

I use CreatePopupMenu and InsertMenuItem, much the same thing.

To add items to a menu, use the InsertMenuItem function. The older AppendMenu and InsertMenu functions are still supported, but InsertMenuItem should be used for new applications.

For a context menu I use this to handle WM_RBUTTONUP

Code Select Expand

mainpopup  proc hwnd:HWND,lparam:LPARAM ;parameters from WndProc
    local  pt:POINT
    movsx  eax,word ptr lparam
    movsx  edx,word ptr lparam+2
    mov    pt.x,eax
    mov    pt.y,edx
    invoke ClientToScreen,hwnd,addr pt
    invoke TrackPopupMenu,mainmenu,TPM_RIGHTBUTTON,pt.x,pt.y,0,hwnd,0
    ret
mainpopup  endp


[NoCforMe]

Interesting.
For my popup (right-click context) menus I use this:

Code Select Expand

MOV EAX, lParam
MOV EDX, EAX
AND EAX, 0FFFFH
MOV pt.x, EAX
SHR EDX, 16
MOV pt.y, EDX
INVOKE ClientToScreen, hWin, ADDR pt ;Where is our client in the "real world"?
INVOKE TrackPopupMenuEx, hMenu,
TPM_LEFTALIGN or TPM_TOPALIGN or TPM_RETURNCMD or TPM_RIGHTBUTTON or TPM_VERNEGANIMATION or TPM_VERTICAL,
pt.x, pt.y, hWin, NULL

I've always been a bit stumped by what, exactly, TPM_VERNEGANIMATION is (or how to pronounce it). But hey, it works ...

(BTW, your code to get x and y from lParam is better than mine; this was written before I started using MOVSX.)

[sinsi]

(BTW, your code to get x and y from lParam is better than mine; this was written before I started using MOVSX.)

Systems with multiple monitors can have negative x- and y- coordinates

Hence the need for MOVSX.

[zedd151]

I've always been a bit stumped by what, exactly, TPM_VERNEGANIMATION is (or how to pronounce it). But hey, it works ...

TrackPopupMenu 

Scroll down to see what TPM_VERNEGANIMATION does. "Animates menu from bottom to top". Probably works fine without it.

Vertical negative animation apparently.

[sinsi]

Yabbut... that is a lot of code and data, just for the sake of not using a resource based menu. I have used similar methods too, but always fall back to using a resource menu. Especially if there are many sub menus and/or menu items.
There are some things that an .rc file handles more easily and efficiently than doing it in the source file. This being one of them, imho.

A bit off-topic but I don't like resources due to the fact that it is easy to change them (BeginUpdateResource etc.)
Anything from a practical joke (hah, this menu says "shit" lol) to nasty (infected images).

[zedd151]

A bit off-topic but I don't like resources due to the fact that it is easy to change them (BeginUpdateResource etc.)
Anything from a practical joke (hah, this menu says "shit" lol) to nasty (infected images).

Then again it's easy to change any strings with a hex editor, whether it is in resources or not. If a hacker/spammer/script kiddie is determined enough, not a lot can be done to stop them entirely, if that is the type of thing that you are talking about.

[NoCforMe]

Scroll down to see what TPM_VERNEGANIMATION does. "Animates menu from bottom to top". Probably works fine without it.

Probably.

Heh; makes me wonder how much stuff like this is in my code that although it works OK, could do without it (or might actually be better done without).

Or conversely, how much of my code works OK but would be better if some small thing was added.

[NoCforMe]

A bit off-topic but I don't like resources due to the fact that it is easy to change them (BeginUpdateResource etc.)
Anything from a practical joke (hah, this menu says "shit" lol) to nasty (infected images).

Well, here's another small advantage I see to not using resources in this case (menus):
If you use a resource editor, you need to duplicate the IDs attached to each menu item by copying them from your code to the resource file (or vice versa).
And if you change them in one place you have to change them in the other to keep them in sync.
I was going to say you could put them in an include file, but you can't, as the resource compiler only recognizes C header files, not assembly-language EQUs. (You can use include files in C/C++.)
With this method there's only one set of IDs and they're right in the source code.

[Vortex]

A menu editor can do also the job. The visual menu designer outputs BCX Basic code. It's easy to convert the BCX code to assembly :

Code Select Expand

' -------------------------------------------------------------------------
'        BCX Menu Creator Copyright 2001-2008 by Doyle Whisenant
'                      mekanixx@gmail.com                 
'
'    Paste this code into your program and call the function
'              to add the menu code to your program.         
'
'              Usage:  AddMenu(hParent)
' -------------------------------------------------------------------------

FUNCTION AddMenu(hwndOwner AS HWND) AS BOOL
CONST  ID_MENU0=9000
CONST  ID_MENU1=9001
CONST  ID_MENU3=9003

'--------------------------------------------------------------------------
GLOBAL MainMenu AS HMENU
  MainMenu=CreateMenu()
'--------------------------------------------------------------------------
GLOBAL FileMenu AS HMENU
  FileMenu=CreateMenu()
  InsertMenu(MainMenu,  0, MF_POPUP, FileMenu, "&File")
  AppendMenu(FileMenu, MF_STRING, ID_MENU1, "&Save")
  AppendMenu(FileMenu, MF_STRING, ID_MENU3, "&Load")
'--------------------------------------------------------------------------
  ' activate menu
  IF NOT SetMenu(hwndOwner, MainMenu) THEN
    FUNCTION=FALSE
  END IF
  FUNCTION=TRUE
END FUNCTION


[jj2007]

Well, it turns out to be really pretty simple to create menus "on the fly" within your code, requiring zero resources other than some text strings.

Attached a minimalistic Windows GUI application - no MasmBasic required, less than 100 lines and fully functional, with a menu and an edit control. Use it as a template together with the Iczelion tutorials.

[jj2007]

GuiParas equ "A menu without resources, hooray!!!!", b LiteBlueGreen, icon Butterfly
GuiMenu equ @File, &Open, &Save, &Print, -, E&xit, @Edit, Undo, Copy, Paste
include \masm32\MasmBasic\Res\MbGui.asm
GuiEnd

[NoCforMe]

"Honey, did you see that?"
"No, what, dear?"
"That billboard back there. Didn't you see it?"
"No, I guess I missed it."
"Oh, it was just another one of those billboards for something called MasmBasic, whatever that is."
"Oh."

[jj2007]

no MasmBasic required, less than 100 lines and fully functional, with a menu and an edit control