WndProc and thread contexts

Just an update on the problem...when I create the debug version of the code
and run it (outside VS), I'm seeing WndProc and the form running in different
threads. The release version doesn't seem to do this. If I run in the VS
environment, it almost always assigns WndProc, the form, and the mainline
separate threads. Is there any way to override this in the debugger?

"mike2036" wrote:

Hi all,

I'm seeing cases running my application outside the debugging environment
where WndProc is running in a separate thread context from the form and
mainline. This is causing issues trying to post messages from the middleware
since the windows handle is in a different context and therefore the
PostMessage() call returns an INVALID_WINDOW_HANDLE error. Has anyone else
experienced this? Is there a way to force WndProc, the form, and mainline to
all run in the same thread context? Thanks for any help.

-Mike

This is causing issues trying to post messages from the middleware
since the windows handle is in a different context and therefore the
PostMessage() call returns an INVALID_WINDOW_HANDLE error.
Window handles are valid "globally" on the same desktop, and you can
call PostMessage from any thread. The only reason I can see for
PostMessage to return that error is that the handle is indeed invalid
(i.e. the window has been destroyed or the handle contains a bogus
value).

Is there a way to force WndProc, the form, and mainline to
all run in the same thread context?

"the form" is an object and as such doesn't run on any specific
thread. The methods of the object run on whatever thread they are
called on.

I'm not sure what you mean by "mainline".

WndProc should definitely ony be called from the thread the window was
created on.
Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

Hi Mattias,

Thanks for the reply. I think my problem may have something to do with the
fact that my application uses a hidden form to get messages sent to it via
WndProc, and that the window wasn't getting registered because it never went
through its 'load' event...I can see this because after I instantiate the
form, I do a Hide(), and my load event handler for the form never gets
called. If I do a Show() and then a Hide() immediately after, the window
gets 'loaded' by the Show() call, and all the thread ID are the same both
inside and outside the debugger. The windows handle is also valid. So it
looks like it was more an issue with the proper loading of the window than
separate thread IDs.

-Mike

"Mattias Sjögren" wrote:

This is causing issues trying to post messages from the middleware
since the windows handle is in a different context and therefore the
PostMessage() call returns an INVALID_WINDOW_HANDLE error.

Window handles are valid "globally" on the same desktop, and you can
call PostMessage from any thread. The only reason I can see for
PostMessage to return that error is that the handle is indeed invalid
(i.e. the window has been destroyed or the handle contains a bogus
value).

Is there a way to force WndProc, the form, and mainline to
all run in the same thread context?

"the form" is an object and as such doesn't run on any specific
thread. The methods of the object run on whatever thread they are
called on.

I'm not sure what you mean by "mainline".

WndProc should definitely ony be called from the thread the window was
created on.
Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.