Good or evil - SetParent() win32 API between different processes
Asked Answered
T

2

32

The SetParent function takes a child and new parent window handle. This also seems to work when the child window is in a different Windows process.

I have seen a post that claims this is not officially supported, but the current docs don't mention this any more. Is this a flaw in the current docs, or did this behavior change?

HWND WINAPI SetParent(
  __in      HWND hWndChild,
  __in_opt  HWND hWndNewParent
);
Teahouse answered 11/8, 2010 at 15:13 Comment(0)
M
34

You can have a parent-child relationship with the windows in different processes. It's tricky to get it to work right in all cases. You may have to debug various strange symptoms.

Normally, windows in separate processes would get their messages from separate input queues using separate message pumps. When you use SendMessage to a window in another process, it's actually posted to the other window's queue, processed there, and the return is effectively marshaled back to the original process. So if one of the processes stops handling messages, you can effectively lock up the other as well. (That's true even within a process when the windows are created on different threads and the thread queues haven't been attached.)

But when you set up the parent/child relationship among windows in different threads, Windows attaches those input queues together, forcing the message processing to be synchronous. You're no longer in the normal case, but you face the same kinds of problems: a hang in the processing for one window effectively hangs the other process.

Watch out for messages that pass pointers in the params. The pointers will not be valid in the receiving process. (There are a couple of exceptions, like WM_COPYDATA, which recreates the data in the receiving process for you. But even those have limitations.)

You have to be especially careful when the windows are being destroyed. If possible, disconnect the parent-child relationship before destroying either window. If it's not possible, then it's probably best to manually destroy the child window before the parent is destroyed. Normally, destroying a parent will cause the children to be destroyed automatically, but it's easy to get hangs when the child is in another process (or un-attached thread).

In newer versions of Windows (Vista+), you can also hit some security speedbumps if the processes run at different integrity levels.

Thanks to IInspectable who pointed out an error in my earlier answer.

Metapsychology answered 11/8, 2010 at 16:21 Comment(4)
You are wrong about the message queues. When calling SetParent with windows owned by different threads, the system calls AttachThreadInput behind your back. Once that's done, both threads share the same input queue. This is true across processes as well. See Is it legal to have a cross-process parent/child or owner/owned window relationship? and Sharing an input queue takes what used to be asynchronous and makes it synchronous, like focus changes.Devisable
@IInspectable: Interesting! I didn't think AttachThreadInput worked across processes. This seems to add an extra wrinkle: what if each thread has a message pump? With attached thread queues, I'd expect a GetMessage call in either thread to retrieve messages for either window, yet it doesn't seem plausible that a DispatchMessage in thread A could route a message to a WndProc in thread B of a different process. Perhaps the GetMessage will only pull messages for the current thread but they'll just be synchronized? I'm not sure how to correct my answer.Metapsychology
@IInspectable: updated links: devblogs.microsoft.com/oldnewthing/20130412-00/?p=4683 and devblogs.microsoft.com/oldnewthing/20130607-00/?p=4143Butyrate
it wreaks havoc on multimonitor window stations with different resolution settings per monitor, especially when the hosting application is a Windows Forms style program, and the hosted app is Microsoft Office...Reproval
A
-1

Just remove WS_CHILDWINDOW from the child window. It avoid locks.
Sorry, that has not been helped

Asseveration answered 20/5, 2020 at 8:40 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.