Message Routing Anomaly?

[Jim Garrison]

I'm exploring the VIEWEX sample program in order to understand
message routing and how MFC handles it.

The app displays a dialog box containing some radio buttons,
and I'm trying to understand the sequence of events when
I click on a radio button. My initial assumption was that
a click would result in a WM_LBUTTONDOWN being posted to the
app, and that would be dispatched through the message loop.
What I found (using Spy++) is, of course, MUCH more complex,
with a large number of messages being SENT to various windows.
I think I understand most of it, but there's one facet
that still eludes me.

I set a breakpoint in CWinThread::PumpMessage at the statement
calling ::TranslateMessage(), to break only when


m_msgCur.message==0x00A1 || // WM_LBUTTONDOWN
m_msgCur.message==0x0201 // WM_NCLBUTTONDOWN




When I click on one of the radiobuttons, I see a whole cascade
of messages being SENT to the radiobutton's wndProc directly, and
eventually the WM_LBUTTONDOWN is posted (according to Spy++).
However, my breakpoint never trips, which indicates to me that
somehow the WM_LBUTTONDOWN got to the radiobutton class's wndProc
without going through my message loop. If I click anywhere in
the main window but outside the dialog, then my breakpoint trips
(this confirms that I have set the breakpoint correctly).

Spy++ and the VC debug IDE both confirm that there's only one
thread running, so this can't be a case of the message being
handled by a different message loop.

So, how did a posted WM_LBUTTONDOWN get dispatched to the radiobutton
without passing through my message loop? What have I missed?

TIA

Jim Garrison
[email protected]

I believe that, within the DoModal call for a modal dialog, there is a separate message pump that processes the dialog's message but ignores non-dialog messages, thus producing "modality".

[Jim Garrison]

Hmmm.... I thought of that earlier, but discarded it since the dialog is being displayed
non-modally (it's a CFormView descendant). Would there still be a separate message
pump in that case?

Unfortunately, I do not have my VC++ books with me today (I believe that MFC Internals and/or Kruglinski's Inside Visual C++ may have a discussion of the issue). If I get a chance to take a peek at them this weekend and come up with anything, I'll tell you.