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