How does windows forms message routing work?

  • Thread starter Thread starter Buddhist.CHinA
  • Start date Start date
B

Buddhist.CHinA

These day, I got a problem when I'm writing a mixed program - there
seemed to be some events missed in message routing!

In my case, when I clicked into a native window, WM_LBUTTONDOWN and
WM_LBUTTONUP should get handled in this window's wndproc. But the
WM_LBUTTONUP events seemed disappered.
Then I have to monitor how these button events work, I got the below
info,

msg.hwnd
2883828 WM_LBUTTONDOWN // native WndProc
2294248 WM_LBUTTONUP // catch this just before
DispatchMessage()
2294248 .NET WM_LBUTTONUP! // managed WndProc

Uh! The WM_LBUTTONUP event had gone to the managed window's wndProc.
Since the first column indicates the target window handle, so we can
notice that the WM_LBUTTONUP's target get changed!!!

First of all, I have one question that, the events caught by native
window's { GetMessage; DispatchMessage} still can be sent to managed
window in the native message routing?
Looks like it's possible in my case.
But I thought the {GetMessage; DispatchMessage} process should be
independent between native and managed window. That means, Windows is
responsible for managing these events to correct targets. So all events
caught by GetMessage should only belong to this window.

I am a little confused. Can some guy give me a hint?
thx.
 
Hi,

I'm little confused also. Forgive me for saying that, but I don't quite
understand what you are saying here.

Managed, native windows there is no such a thing. There are managed classes
for controls, but there is only one type of windows and there are native for
Windows OS. All native controls have underlaying native windows which
provide the drawing surface as well as receive notifications from the OS in
a form of windows messages. The messages are routed and delivered to the
underlaying native windows as per Windows rules. The WinProc of these
underlaying windows takes care of raising different events which are part of
the managed controls. There one little place where the framework interfere
with the normal message flow and this is with reflecting notifcation
messages, so they can be handled on the level of the child control insted on
the level of the parent window.

Anyways dispatching mouse messages is not altered in any ways.

Can you post some sample code that demonstrates your problem?
 
"The WinProc of these underlaying windows takes care of raising
different events which are part of the managed controls."

The windows form controls are still built on underlaying native
windows, which take care of raising events to managed controls. Right?

In my case, I have a mixed programming application. Given that there
are a native window as the parent window, and a managed window as the
child window.
At some moment, when I clicked on the beneath native window, however,
the mouse event went to embedded managed window. So I'm wondering at
this point.
And my question is,

// after the click, I caught the WM_LBUTTONUP here,
while (PeekMessage (&msg, NULL, 0, 0, PM_REMOVE))
{
TranslateMessage (&msg);
DispatchMessage (&msg);
}

but, the WndProc of the native window didn't respond to this event. In
constrast, the WndProc of the managed window captured and processed the
WM_LBUTTONUP event.
Why was this event dispatched to wrong WndProc?
I thought all events in preceding loop should only be dispatched to
WndProc of native window. The windows system determined it only can go
to WndProc of native window, at that moment.

thx.
 
Hmm, strange... The mouse message should be dispatched to the window under
the mouse cursor, unless some window has set mouse capture. Windows forms
controls set the capture when the mouse has been pressed down and release it
when the mouse is up. Is it possible that something goes wrong there?
Unfortunately without some sample for me to fiddle with is hard to say what
the problem might be.
 
Back
Top