The evolution of dialog templates – Introduction

In the history of Windows, there have been four versions of dialog templates. And despite the changes, you'll see that they're basically all the same.

My secret goal in this six-part series is to address questions people have had along the lines of "I'm trying to generate a dialog template in code, and it's not working. What am I doing wrong?"

As it turns out, that you can get the resource compiler to tell you what you're doing wrong. Take the template that you're trying to generate, create an *.rc file for it and run it through the resource compiler. Attach the resource to a dummy program and dump the bytes! Compare the compiler-generated template against the one you generated. Look for the difference.

In other words: To see what you're doing wrong, take somebody who does it right and compare. Clearly there's a difference somewhere. It's just bytes.

Anyway, enough of the rant against laziness. The next several days will cover the evolution of the dialog template, with annotated byte dumps for people who are trying to figure out why their dialog template isn't working.

Non-geeks may want to go into hibernation for a while, since this will take over a week to play out. I'll try to keep you amused with the non-technical side-postings.

Comments (10)
  1. asdf says:

    Because the sample code on MSDN (even after you correct all the errors to get it to compile) and documentation are incorrect. I should know, I spent a few days days reverse engineering dialog templates and the undocumented hack in windows that prevents you from getting message box fonts to work unless you use their little font size hack. When I get back home I’ll post an article about dialog templates too so the rest of the people can play along at home.

  2. Mike Dimmick says:

    Maybe I was reading different documentation to you, then, because it worked fine for me.

    One of my creations (Large Keyboard for Pocket PCs – parses dialog templates to draw the keyboard ‘tabs’ so that the developer adapting it can use the resource editor to draw a keyboard. It isn’t actually used as a dialog resource, for two reasons: firstly, the rounding errors in the font mapping can lead to overlaps, odd line thicknesses or gaps, and secondly that an array of buttons is slow and doesn’t work too well when embedded in a Pocket PC input method (not to mention weird focus behaviour).

    Yep, I could have written my own editor. Indeed, it’s actually easier to punch in the numbers so I edit the resource script by hand to make changes.

    I’d previously used dialog template construction (successfully) in a build-your-own-forms-style application; however, I realise now that it’s simpler to just create the child controls and use IsDialogMessage to provide the standard dialog navigation behaviour. There was a certain amount of fudging of sizes involved, again due (I think) to the dialog unit mapping rounding problem.

  3. asdf says:

    "Creating a template in memory" specifically. But there were lots of incorrect statements scattered around MSDN from what I rememeber.

    I agree with you on the build your own dialogs and use IsDialogMessage but you still have to write code to remember the focus, set the fonts, use the dialog units code I posted on this blog a while ago (which I highly recomend because doing it in dlgu makes the dialog look so much better especially if you support resizing), and optionally make your own modal message loop. Should take an hour or two.

  4. mschaef says:

    " agree with you on the build your own dialogs and use IsDialogMessage but you still have to write code to remember the focus, set the fonts, use the dialog units code "

    So why were templates done originally? Were they the best way to implement the functionality you mention, or was it primarily for programmer convenience?

    Part of the reason I ask is that I’ve spent way too much time trying to develop libraries of reusable windows using MFC and Visual Studio. VS seems to work really well if the assumption holds true that all resources (and compiled dialog templates) are in the same file. Once that assumption changes, things seem to get pretty tricky. Life seemd like it would be easier in this respect if it was done programatically by explicitly creating windows.

  5. asdf says:

    Two main reasons (three if you count ripping off the Mac). The first one is so you can use a UI editor. The second one is to support different languages with the same binary. These both take advantage of dialog units because if you change the the size of the fonts, the dialog box should look the same (in theory). Set your fonts to use a large dpi and see how many apps get this part wrong.

    Programming dialog boxes is a different beast than programming a real window (there is a really old blog entry somewhere here that shows how to get it DefWindowProc style instead of dialog box style). Most of the time dialogs are just copy and paste coding with validation thrown in and doing it dialog style with templates is easier and less code (if you’ve ever done tabs manually vs property pages with dialog templates, you’d know). If you want to support resizing, custom fonts, or anything else fancy it’s much easier to use IsDialogMessage and roll your own. It’s another hour or two of work if you want to parse the dialog templates and create the windows yourself.

  6. Mike Dunn says:

    Life seemd like it would be easier in this respect if it was done programatically by explicitly creating windows.

    That’s how it’s done in Windows Forms and personally I find it much uglier than using an rc file.

    For resizing (in normal C++) WTL’s CDialogResize is da bomb.

  7. asdf says:

    Sorry for the half assed documentation, I’m tired as hell. The code is pretty self explanatory with just the sample code that shows what’s going on.

  8. Ben Hutchings says:

    asdf: I thought a major reason for using templates was to save on code size. A bunch of dialog resources plus some generic code to instantiate them is surely smaller than the specific code to create the controls for each dialog.

  9. Trying to capture the changes in a table.

Comments are closed.