The dialog class goes under the sneaky name WC

The dialog class goes under the sneaky name WC_DIALOG

Date:	August 31, 2006 / year-entry #296
Tags:	code
Orig Link:	https://blogs.msdn.microsoft.com/oldnewthing/20060831-22/?p=29903
Comments:	15
Summary:	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.

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)

FlorianW says:

August 31, 2006 at 10:06 am

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:-)
mastmaker says:

August 31, 2006 at 10:24 am

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.
Steve says:

August 31, 2006 at 10:43 am

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

August 31, 2006 at 11:31 am

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.
mastmaker says:

August 31, 2006 at 1:01 pm

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

August 31, 2006 at 3:23 pm

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.
wysiwyg says:

August 31, 2006 at 9:15 pm

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

September 1, 2006 at 12:04 am

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]
Norman Diamond says:

September 1, 2006 at 6:05 am

[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]
James says:

September 1, 2006 at 6:20 am

"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.
Neil says:

September 1, 2006 at 7:19 pm

MAKEINTRESOURCE(32770) used to work too.
James says:

September 2, 2006 at 5:53 am

"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… :-)
Norman Diamond says:

September 3, 2006 at 11:26 pm

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.
Dewi Morgan says:

September 4, 2006 at 8:43 am

> 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.
Jules says:

September 4, 2006 at 6:29 pm

"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.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

A "redesign" after 2019 erased thousands of user's comments from previous years. As many have stated, the comments are nearly as important as the postings themselves. The archived copies of the postings contained here retain the original comments.
The blog has changed domains many times and the urls have otherwise been under constant change since 2003. Even when proper redirection has been set up for those links, redirection only works for a limited period of time. For example, all of the internal blog links that were valid in early 2019, were broken by 2020 without proper redirection.
The blog has been under constant re-design and re-theming since its inception. It is downright irritating to deal with a bogged-down site experience as the result of the latest visual themes designed for cell-phone browsers. As of this writing, it is cumbersome to navigate titles with only 10 entries per page. While it is nice that the official site has a search feature, searching using this index (with all titles on a single page) is much quicker (CTRL-F in most browsers).

<-- Back to Old New Thing Archive Index