The dialog class goes under the sneaky name WC_DIALOG


An anonymous commenter wanted to know how to create a dialog box with CreateWindow. The window class for dialog boxes is WC_DIALOG. I'm not quite sure why anybody would want to create a dialog box this way, but there you have it.

Comments (15)
  1. FlorianW says:

    Well, It’s usefull for writing tutorials for win32 api programming where you don’t want to shock the developer with the class function in the hello world example.

    But I most admit, I used the button class for this:-)

  2. mastmaker says:

    For one of our products, I was forced to create a CNonDialog class which would SIMULATE the entire functionality of the dialog. This is because the CDialog painter would assume a rectangular region for the window (for the purposes of background filling) which would make it look like my oval dialog had smudges around the edge. I am sure this happened in Win2k. Haven’t tried it in XP.

  3. Steve says:

    I’ve always used "#32770".  Is that the same?

  4. Anonymous says:

    Perhaps they’re writing a 4k or 64k demo, and they want to save a few bytes in the exe by not needing to link against the CreateDialog function.

  5. mastmaker says:

    Sorry for the mistake. It was CButton class that had the problem with non-rectangular window regions. So, I came up with CNonButton class.

  6. Jules says:

    I didn’t actually use the approach of creating a dialog directly, but when I wrote an application framework that used a different resource format for describing dialog boxes, I effectively abandoned the use of the DialogBox (etc) functions.  

    In the first version I just used DialogBox (or CreateDialog) with a constructed template that created a dialog of the right size, then created controls in response to WM_CREATE.  I eventually abandoned this approach because you can’t get pixel-resolution sizing this way, as the size of a dialog is specified in dialog units (of course).

    So, in the second version, I created dialogs by using CreateWindow and used my own implementation of modality to provide an ‘execute()’ method on my dialog class.  I didn’t use the standard Windows’ dialog class, cause I figured that by the time I’d done this, and called IsDialogMessage, and so on, there was nothing left in the standard class that was useful to me.  So I just registered my own class for dialog boxes and let it go from that.

    The Windows dialog template system is showing its age a bit, I think.  Last time I used it, it was showing signs of stress around the edges, particularly when it came to creating the C++ objects that managed the custom controls that were created by it.

    Maybe its just me, but I prefer a dialog-creation system that’s completely integrated into my framework and which does the object creation too.

  7. wysiwyg says:

    A proper dialog system should not rely on a existing GUI. And most important, a dialog system should not dictate program flow.

  8. Norman Diamond says:

    Thursday, August 31, 2006 3:23 PM by Jules

    > I eventually abandoned this approach because

    > you can’t get pixel-resolution sizing this

    > way, as the size of a dialog is specified in

    > dialog units (of course).

    I think that there are APIs that will figure out how many pixels you have and how many you need for each control, but … well, maybe this would be a candidate for the suggestion box.  As far as I could tell, for each control that uses a different font from the dialog box’s main font, I would have to create a new separate invisible dialog box, set that one’s font to the one we do computations with, call the APIs and do some computations, etc.  I gave up.  I think it’s possible, but if I tried it I’d probably get fired for wasting the amount of time that would take.

    Meanwhile some header files declare a constant named

    DS_USEPIXELS

    Now what would that be for?  We don’t know any company that would dare to make internal use of such an enormously useful feature while preventing everyone else from using such an enormously useful feature.  And it is 100% fully undocumented, as far as I can find.  So what in the world is this declaration doing in some header files?

    [I like that strategy. Make up a theory and then start accusing people of cheating because they didn’t tell you about the theory that you made up. -Raymond]
  9. Norman Diamond says:

    [I like that strategy. Make up a theory and

    > then start accusing people of cheating

    > because they didn’t tell you about the

    > theory that you made up. -Raymond]

    Well, now I’m even more confused than by your word games in your recent non-computer thread.

    I might or might not have a theory that Microsoft is making internal use of such an enormously useful feature even after Microsoft issued settlement documentation of some APIs and network protocols.  But even supposing I have a theory that Microsoft would still dare to do such a thing, then you say that my reason for accusing people of cheating is because they didn’t tell me about my theory?  Supposing that I have such a theory, my reason for accusing people of cheating wouldn’t be that they withheld publication of DS_USEPIXELS?  Mr. Chen, both you and I have moments when we aren’t as logical as we usually are, but this nonsense looks particularly extreme.

    Meanwhile, if Microsoft weren’t using DS_USEPIXELS, and since no one else can use it, I still wonder how that declaration got into some header files.

    [Thanks for being vague. I eventually found what you’re referring to, and you conveniently omitted mentioning a critical detail:

    #if(_WIN32_WCE >= 0x0500)
    #define DS_USEPIXELS        0x8000L
    #endif
    

    It should be blatantly obvious from the #if that this is a Windows CE-only style. You can take this up with the Windows CE folks. It boggles the mind that that seeing a Windows CE-only style not documented in the Platform SDK (which covers Windows NT not CE) can lead to accusations that this “undocumented” style is being used “secretly” by a platform that doesn’t even support it! You owe me two hours of my life back. -Raymond]

  10. James says:

    "Meanwhile, if Microsoft weren’t using DS_USEPIXELS, and since no one else can use it, I still wonder how that declaration got into some header files."

    It would be nice to get a clear answer – or, better still, a documented API for doing it – but it seems the explanation is just "It’s something used in WinCE but not Win32", which is why it’s #ifdefed out in the SDK. Rather like the internal build test script written in Perl which managed to sneak into the WinXP CDs: accidental leakage, rather than proof MS is part of the alien conspiracy to distract us from UFO sightings with their fake crop circles.

  11. Neil says:

    MAKEINTRESOURCE(32770) used to work too.

  12. James says:

    "You owe me two hours of my life back. -Raymond]"

    Well, you could have saved an hour and three quarters of that by reading my post (fifteen minutes after Norman’s) where I pointed out it’s WinCE-only and if’ed out in the SDK headers… :-)

  13. Norman Diamond says:

    It should be blatantly obvious from the #if

    > that this is a Windows CE-only style.

    So what?  As already stated, as far as I can tell it’s 100% undocumented.  That doesn’t mean undocumented in the Platform SDK, it means undocumented in all of MSDN, undocumented in the Windows Mobile 5.0 Developer Resource Kit, undocumented in the Smartphone SDK and Pocket PC SDK, undocumented in the Knowledge Base, and even undocumented in the most reliable well-known documentation system that some Microsoft employees ever obtained permission to publish (blogs.msdn.com).

    I was guessing that Microsoft wouldn’t dare to use this thing internally after certain well known settlements and court cases, and therefore can’t imagine what purpose the declaration could serve.

    But just now I figured it out.  Certain well known settlements and court cases pertain to "big" Windows systems not to Windows CE.  So Microsoft is free to continue its usual practices.  So that must be why I was accused of having a conspiracy theory and some other stuff that I still haven’t figured out yet, though even this much of a conspiracy theory I hadn’t figured out until starting this paragraph.

    > You owe me two hours of my life back.

    Google is still capable of finding some Microsoft things a lot quicker than two hours, and a few weeks ago this was one of them.  If that’s been disabled then maybe a conspiracy theory needs expanding.

  14. Dewi Morgan says:

    > I didn’t use the standard Windows’ dialog class,

    >> cause I figured that by the time I’d done this, and

    >> called IsDialogMessage, and so on, there was nothing

    >> left in the standard class that was useful to me.

    If this library was distributed, you probably ought to look far, far beyond "useful to me".

    Do your dialog contents copy with Ctrl-C? Are they readable with screen readers? Do they make the system-wide user-defined event sounds when displayed? Do they use system-wide user-defined styles? Do they deal correctly with all fonts and things like BiDi text?

    The reason we don’t all rewrite stuff from scratch isn’t because the MS stuff is perfect, nor because it’d take us too much time: it’s an accessibility thing.

    I’m in a glass house for this one, though, being guilty of it myself: I’m rewriting a bunch of Java text components as lightweight ones. This was because there’s no other portable way to get component transparency in a Java 1.1 applet without Swing. In doing this, I’ve killed accessibility, so I must provide an option for users who need the behaviour of the standard, non-transparent components.

  15. Jules says:

    "Do your dialog contents copy with Ctrl-C?"

    If an edit control has focus, the usual shortcuts like this work.  I can’t find any other system behaviour related to this, so I assume this must be what you’re talking about, so the answer is yes.

    "Are they readable with screen readers?"

    Yes, at least with Narrator anyway.  And I didn’t have to do anything special to make it work, either.  Screen readers are quite smart, these days.  They seem to infer a lot from tab order, but as long as you’re sensible with window creation order that’s fine.

    "Do they make the system-wide user-defined event sounds when displayed?"

    I’ll admit they don’t do that, and probably should.

    "Do they use system-wide user-defined styles?"

    They use standard Windows components.  They’ll use user-defined styles as much as any other window does.

    "Do they deal correctly with all fonts and things like BiDi text?"

    As long as the Windows API functions for measuring the size of text work correctly, then yes.  Probably better than the standard dialog manager, because a dialog layout could easily break if you changed a dialog using that between two fonts with wildly different character spacings (e.g. a proportional font to a monospaced one… most of your spaces aren’t going to be wide enough any more).

    I had very good reasons for breaking from the standard dialog manager’s control creation mechanism, namely that it wouldn’t measure the size controls actually need to be, and relied on me specifying sizes, which I felt didn’t work very well for environments where such things could easily change (especially seeing as the library in question needs to work cross-platform).

Comments are closed.