The evolution of menu templates: Introduction


As with dialog templates, menu templates have also gone through a four-stage evolutionary process. People don't often generate menu templates in code, although the LoadMenuIndirect function is there waiting for you once you get the urge. As a result, there aren't many questions from people trying to generate menu templates dynamically, but I'm going to go into the history of menu templates anyway, just out of a sense of completeness.

If you're having problems with your dynamically-generated menu templates, you can ask the resource compiler to tell you what you're doing wrong by createing a *.rc file for it and compiling it into a scratch program. Dump the resource as bytes, and there's your answer. Same trick we used for dialog templates.

Comments (2)
  1. Jamaw At Nouals says:

    A pity menuitems and accels can’t be linked together, instead you have to put the accelerator of a menuitem in its string, seperated by a TAB character, like NewtCtrl+N. This way of doing this (almost) never takes into account Apple keyboards, layouts with a seperate Alt and AltGr and probably some others I can’t think of right now.

    At some point I wanted accelerators to "just work" so I wrote a function that walks through the menu to generate the corresponding accelerator table, and just "be done" with it. I think it would’ve been better to write a function that combines LoadAccelerators and LoadMenu, adding the textual representation of an accelerator (with matching id) as it creates the menu. It’d only have to deal with 1 version of menu template, so it would be relatively simple.

  2. Yuhong Bao says:

    On the matter of 16-bit extended templates, what was not so well known about Win9x is that it allowed some of its new features (not all, but most of the exceptions are related to the shell, for example none of the common controls introduced after Windows 95 can be used), including, of course, this, to be used by 16-bit applications WITHOUT thunking. In fact, in older versions of the Win32 SDKs there was a 16-bit RC utility that you could use to actually mark your app as version 4.0, and the Win9x DDKs had 16-bit header and library files that allowed you to program 16-bit apps that take advantage of Win9x. Most of this support probably came from early 95 development (for example, as mentioned in another blog article, the Cabinet shell was built in both 16-bit and 32-bit). It was not documented of course, and I wonder why?

Comments are closed.

Skip to main content