Why do we need IsDialogMessage at all?

alv wonders why we need the IsDialogMessage function at all. "All its activity could take place inside the window procedure of the modeless dialog itself", since when it doesn't have focus, it shouldn't be responding to messages anyway.

Sure, that works great if the modeless dialog has focus. But it almost never does. What has focus is a control inside the modeless dialog. And in that case, the modeless dialog never sees the message, since the rule is that keyboard messages go to the window with focus. And that ain't the modeless dialog box.

Consider, for example, a message box with OK and Cancel buttons. Focus defaults to the OK button. You hit the TAB key to move to the Cancel button. The TAB message goes to the OK button because it is the control with keyboard focus. The OK button says, "I don't know what TAB means. I guess I'll just beep." (The button control doesn't know whether it's part of a dialog box or not; it just worries about being a button.)

The IsDialogMessage function is in the message loop so that it can intercept the TAB message before it reaches the OK button. At this point, IsDialogMessage can step in and say "Hang on, I'll take care of this" and use the TAB key to perform dialog box navigation. (Of course, as we know, it first checks with the control that stealing the message is okay.)

Some progamming frameworks capture the concept of "stealing messages" with names like PreTranslateMessage and event routing. But the basic idea is the same: Letting somebody other than the target of a window message get a chance to intercept the message and do something special with it.

Comments (4)
  1. Random832 says:

    I think this misconception may be in some part based on the HTML event model, where inner "controls" [elements], like the OK button, naturally pass the event on to the parent if they do not handle it themselves. (or the other HTML event model, where the parent control is always given all events and can choose to handle it itself or give it to the relevant child element – in either case, nothing special has to happen for the dialog to handle "tab", since the button clearly isn't interested in it.)

  2. Joshua says:

    Wow, I reinvented IsDialogMessage once.

  3. Andrew says:

    Sometimes I skip an entry since it seems so high above my head in Windows API world, but I gave this one a shot and learned something interesting about Windows and events in general :) I'll take this lesson with me.

  4. alv says:

    Thanks for the explanation! I also see now that I formulated my question in a misleading way; instead of 'has focus' I should've written 'active'. Let me explain: This question came up when I was to develop and add-on to a somewhat large software suite, and part of the project was displaying a modeless dialog. I didn't have access to the main message loop (not even read-only access to the source code), and because of other constraints having my own message loop in a separate thread or process wasn't feasible either. Therefore, I had to reimplement the functionality of IsDialogMessage inside the dialog. I would've been very happy if there had been some way of telling Windows 'Hey, here is my modeless dialog, please incorporate it in some magical way to the message loop', and of course deregister it afterwards – for example when handling the WM_ACTIVATE message.

Comments are closed.

Skip to main content