Reputation: 509
I'm developing a multi-process framework for a complex application. A Host process acts as a container, and one or more guest processes can be spawn from it. A Window of such guest processes is reparented to a Hosts's window (such as a notebook tabSheet). (InterProcess Communication is not an issue here - it works) Imagine something similar to Google Chrome. I've read many answers about reparenting windows across processes, but I can't figure out what's happening in this case:
WaitForMultipleObjects
on some Handles;MessageBox
, but hangs.Doesn't the guest process run on a separate message queue? What am I missing?
I think I followed the best guidelines about SetParent
when I embedded the Guest Form:
SetWindowLong(GuestHWnd, GWL_STYLE, GetWindowLong(GuestHWND, GWL_STYLE) and WS_EX_NOPARENTNOTIFY and (not WS_POPUP) or WS_CHILD);
SetParent(GuestHWnd, HostHWnd);
PostMessage(GuestHWnd, WM_UPDATEUISTATE, UIS_INITIALIZE, 0);
SendMessage(HostHWnd, WM_UPDATEUISTATE, UIS_INITIALIZE, 0);
SetWindowPos(GuestHWnd, 0, 0, 0, 0, 0, SWP_NOMOVE or SWP_NOSIZE or SWP_NOZORDER or SWP_FRAMECHANGED);
Notice also that I haven't called any sort of AttachThreadInput
.
The problem doesn't arise if the Host is not blocked, or if the Guest window is not a child of a host's (obviously).
Thank you.
Upvotes: 1
Views: 180
Reputation: 1051
I can only recommend Raymond chen's explanation to this: http://blogs.msdn.com/b/oldnewthing/archive/2013/04/12/10410454.aspx
Long story short:
Creating a cross-thread parent/child or owner/owned window relationship implicitly attaches the input queues of the threads which those windows belong to.
The problem is in this statement:
Notice also that I haven't called any sort of AttachThreadInput. The problem doesn't arise if the Host is not blocked, or if the Guest window is not a child of a host's (obviously).
Since it's a child/parent relationship, there IS an implicit AttachThreadInput.
Upvotes: 1