| Date: | July 12, 2007 / year-entry #252 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070712-00/?p=26043 |
| Comments: | 29 |
| Summary: | Somebody I'd never heard of sent me email with a general programming question. (This is one of the top ways of instantly making me not interested in talking to you.) I have a modal dialog box which I hide with ShowWindow(SW_HIDE), and I want to enable the parent window so the parent window will get... |
Somebody I'd never heard of sent me email with a general programming question. (This is one of the top ways of instantly making me not interested in talking to you.)
This is like asking for a cheeseburger and then trying to peel every last bit of cheese off the patty to turn it into a plain hamburger. Since the cheese has already melted into the crevices of the burger, you're going to be picking off tiny flecks of cheese for a long time. If you want a modeless dialog box, then just make a modeless dialog box. (This is what MSDN is trying to tell you in slightly more polite language.) |
Comments (29)
Comments are closed. |
I think this is a case of a programmer not really understanding Windows. Granted, that takes years, dedication, and patience. But many people just assume things work a certain way and that’s it.
I’d assume this guy doesn’t even know what a modeless dialog is, or what "modal" even means.
Yeah, I read almost everything I can get my hands on to try and keep up. It’s a lot of work, and sometimes I still ask stupid questions or miss key points. It happens, but you can usually tell who is trying and who just wants you to write their code for them.
Ok but that quote from MSDN is not telling him to create a modeless dialog. It is telling him not to create a modal dialog. A small difference. The questioner needs something like psychic debugging skills for understanding what the statement is implying but not stating.
C’mon, there are only modal and modeless dialogs, if the article says don’t do that with a modal dialog, there’s only one thing left to do, right?
Sure – Raymond, You and I know that. And someone who doesn’t shouldn’t bother us with their stupid questions.
Not to mention that in Petzold’s Programming Windows books, he goes through both modal and modeless dialogs. So his only excuse for ignorance is not seeking the information.
This is a case of someone not taking the care enough to learn what he is doing on any level.
Reminds me of some code I saw at a company I was working for. It went something like this:
CModelessDialog dlg;
dlg.doModal();
(CModelessDialog was a CDialog derived class)
I can certainly understand that a novice programmer might need to ask questions like the bazillion books, articles, examples, etc. ththat (and get a reasonable answer), however, I don’t expect that Raymond’s email box should be the target of those questions for people he doesn’t even know.
It’s one thing for the guy in the cubicle next to me or the office down the hall to ask me questions like that. It’s another thing for someone I know nothing about send me an email asking for a basic Windows programming tutorial.
It’s not like there aren’t any resources available for learning basic Windows programming.
I hear what’s being said here, but I’m sure it’s something I went through a long time ago.
Sometimes these things aren’t so obvious, and nobody is prepared to grant you the time.
That’s learning the hard way.
One thing that still stands out for me in respect of windows dialogs. It’s something I guess I’ll never understand……
Why was it necassary to have a different function prototype for "DialogProc" as "WindowProc"?
If, like me you have a single entrypoint per thread for WindowProc, and a lookup that directs the call to the class wrapper instance you wrote for an HWND, then having to have a separate lookup for dialogs, in the sole and rare (but useful) situation that they are modal, is annoying.
I know that Raymond thinks that other people write poor implementations of the dialog manager. He said so a couple of days ago. Being that I am only a half rate programmer, he’s probably right.
I often find myself thinking that something MS have done, seems dubious. Almost as often I find myself discovering why things have been done the way they are. At the end of the day there aren’t many functions in the Win32 api that I find myself thinking they’re tardy, in fact it’s usually the opposite. Someone somewhere must know something!
The separate DialogProc is one of those that has always left me with some doubt as to the reason. No doubt there is a simple answer that will make me look foolish, so I choose to remain as anonymous as I can.
For the nitpickers;
"modal, is annoying."
Should read….
"modeless, is annoying."
I think Raymond’s answer (and everyone else who have replied so far), completely miss the mark.
The anonymous programmer has a modal dialog that he wants to hide temporarily.
Proposed solution? Don’t use a modal dialog.
Uh?
Correct solution: save the dialog state, close the dialog, re-open it when needed.
Everyone seems to assume that it’s modal for no reason.
ROFL!
I never like the "are keyboard accelerators underlined" option anyhow!
Not that this is directly the issues, but I’ve always wished Modal and Modeless had been named differently from the start.
I work with seasoned developers who still get the two mixed up. The words don’t intuitively tie in with the functionality.
If it’d been called "AlwaysUpPersistantWithFocus", for example, someone would know there must be a "NotAlwaysUpWithFocus" option out there.
"Modal" doesn’t necesarily convey that.
I don’t know about that myself. I get ’em mixed up "cuz I is a clutz". :) Genuinely, I do.
Modal and modless are easy because a modal dialog puts the main message pump into a separate mode (or state – but lets not go there), where modeless doesn’t.
Focus??? What’s that?
:))
I disagree. Years ago AmigaOS had messaging system similar to the one found in Windows and it was not the only OS that had it.
So, the concept was there for the long time and yet people haven’t bothered to grasp it. Their fault, not Windows’.
On a side note the proper solution would be to rethink the application design so you don’t need to make the dialog modeless at the first place. In other words, if you think that the user might need to do something else while in that dialog box, then include it there so they doesn’t have to switch back to parent window.
There was a time when I, like this person, was wondering how to create a modeless dialog… and no clue that that was what I wanted. Luckily I had some source code that did that to refer to.
Sounds like some code at our company. It’s not at all obvious that the author of our internal UI class library knew the difference between modal and modaless dialog boxes. For example, in both cases the dialogs were created with CreateDialogParam. In the case of the modal dialog, the class would then SendMessage WM_INITDIALOG to the new dialog (I have got no idea), EnableWindow(FALSE) its parent, then enter a message loop.
In both modal and modaless flavors, the class closed the dialog with…
(wait for it)
both DestroyWindow and EndDialog, one after the other. Oddly, that DestroyWindow/EndDialog duality outlived the author by a substantial period of time (in fact I personally fixed it a couple weeks ago), and several other people looking at the code.
Needless to say, that UI library is #1 on my list of ‘usual suspects’ when something, somewhere breaks.
Justin Olbrantz:
I recall that in Windows 3.0, the call to DestroyWindow before EndDialog was required, if you were fussy enough to want the dialog to actually disappear.
I just found some code that did that, dated 1993 (but may have been a year or two older). It was in a dialog proc, and looked like:
case WM_CLOSE: DestroyWindow(hwnd); break;
case WM_DESTROY: (do the real work of closing down the dialog) break;
Am I missing something here? I don’t think that changing to a modeless dialog would solve the problem.
Reread the problem statement. It sounds to me that the requirements are for the dialog to behave like a MODAL dialog when it is displayed, but to allow the main window to work normally when the dialog is hidden. The suggestion to make the dialog modeless would make the dialog work properly when it is hidden, but not when it is displayed. Not exactly what was asked for.
RichM: Remember what modal dialog is used for? It’s used as a way for display a dialog that’d change the workstate of parent dialog/window, so that you won’t want your parent window be interactive before your modal dialog is closed and the changes a made.
If that’s not what you want, you probably don’t want a model dialog, but an "always on top" window/dialog.
Oops… I’ve accidentally disabled the spell checker… so much typo there…
Despite the fact that it looks like a stupid question, if you consider that most programmers don’t actually take the time to learn what they’re doing but rather they just copy some code that they saw and seems to work, I can understand where the question is coming from. And in that respect, the comment in the MSDN documentation is useless. Someone who knows the difference between modal and modeless dialog wouldn’t need that comment, and it doesn’t help someone who doesn’t know the difference get "on the right track".
I mean, you even had a post about it this week: "It’s not enough to say that something is bad; you have to say what would be better".
I think the problem was that the guy hadn’t realized that modELESS is the opposite of modAL. It was just a language thing. Mericans aren’t good with languages. The English language is just too difficult for them.
He read the MSDN comment, no wonder he’s confused.
I think that despite the richness of MSDN the old topics concerning COM and Win32 Development need to be updated, even re-written, and embelished with more code examples, more tutorials and step-by-step guides as well ass more details and links to newer would be .NET-based replacements. From my use of the documentation I found quite some mistakes which reporting to Microsoft is not easy at all and which despite all these years appear to be unfixed. When I read some of the Win32 topics I even think that they were written 15 years ago or even more since some of them only talk about Win95 and NT3.5. Yes, I know that newer Windows Forms and WPF technologies are much cooler but isn’t it a shame to have the same quality of documentation for so many years? For me learning Win32 programming from MSDN or from the Web was a pain. Compare this to .NET or HTML+JavaScript programming which is so easier to learn since there are so many tutorials and documentation online. Microsoft could have done better. Now, with the reign of managed code and other technologies such as DirectX, it might be too late to hope for change in old Win32 gui. Imagine having to give your students a project for writing a Win32 api-based application or giving them a Java let’s say application. Which one is easier to learn how to write using on-line resources?
The trouble is, the questioner wants behaviour which is hard to implement. E’s asking the wrong question, though. Using a modal dialog here is not the right answer; either you stay in the modal dialog’s message loop when you return to the main window (and then most likely crash on certain actions, such as closing the main window), or you leave the modal loop (which as Raymond points out means destroying and reconstructing the state).
I suspect that the right question would be more like "I want a dialog which I can show and hide. While the dialog is shown, I don’t want the user to be able to interact with my main window." The most natural implementation (which is actually kinda obvious when you ask the question the right way) would probably be a modeless dialog plus explicit calls to disable and re-enable the main window.
well my diagnostic and reply would be the same as Raymond.
The problem is that no one learns to program window, they just modify existing code and learn from there. People like me would have started with Charles Petzold’s book in the early 90s and did things like the MFC ‘scribble’ tutorial learned the basics and we’re the better for it. I have colleagues who don’t even know what BeginPaint/EndPaint does and why you need it in WM_PAINT!
I think the modal/modeless dialog confusion is specific to programming in C/C++, since amost every sample uses use modal dialog, people think it’s the only way to use a dialog templates. My guess is it’s the reverse in VB.
Also, it really doesn’t help that all documentation in online now. It’s really with printed manuals that you can learn what’s available, where to START looking for something.
I had combed every page of the Window SDK API that I got with Borland C++ 3.1..
msdn library has improved in the last 15 years, you can’t assume everyone has learned everything from the current edition. In the early editions you couldn’t get a clue from the documentation what was happening inside windows.
If you had sold your book THEN you would have outsold Petzold.
Where do the terms modal and modeless come from anyways? To me they have always been made up words and like many others I have trouble remembering which is which.
I also have trouble talking about them to non-programmers. Again, this goes back to them being made up words (or at least words that aren’t in common use anywhere else.)
I think these concepts would be a lot easier if they were renamed. Like BlockingDialog and FloatingDialog.
Yes, Modal and Modeless are probably bad names. But since we have to say what’s better, rather than just complaining… Um, I don’t know. And it’s too late now to change the names.
Taking a cue from mccoyn, I would go back in time and nominate BlockingDialog and NonBlockingDialog.
If Raymond had nothing else to do, I would nominate him to go back and enhance all of the MSDN documentation that applies to dialogs (and any of his other specialities) and add tips, pointers, suggestions, clarifications, "Don’t do this", etc.