Where is the MSDN documentation on multi-process window ownership for win32? (chrome uses this)

Question

where is the MSDN documentation that describes how multiple processes can control and own other windows in other processes like Google chrome?

Answer 1

Hmmm, I just mocked up an example, and if I open up Notepad, and open up an explorer window, I can do the following, no trouble:

HWND hNotepad = FindWindow (NULL, TEXT("Untitled - Notepad"));
HWND hMusicFolder = FindWindow (NULL, TEXT("Music"));

SetParent (hMusicFolder, hNotepad);

This puts my music folder window inside Notepad, each window belongs to its own process, which is not even my own process. Oh dear.

This was done on XP SP2.

Answer 2

You can use FindWindow to find a handle in another process. There is a whole series of messages which can be used to traverse the window hierarchy to find handles.

You can then manipulate the handles using PostMessage.

There is a library WTL which microsoft gives out the source. You can use that library because controls in there all have an Attach method that can attach to any window handle. You might need to hack it a bit to use PostMessage instead of SendMessage.

Answer 3

I don't believe there is any explicit documentation on this, because nothing directly in the Win32 API that supports that. You can use SetParent or SetWindowLongPtr with GWLP_HWNDPARENT to change to window's parent and owner respectively and you are free to any window message you like to another processes window with SendMessage().

If you want to move any data between two difference processes you are looking at Inter-process Communication (IPC), which Windows has several ways to do.

Answer 4

I don't know that Chrome does it the same way, but out of process COM servers have been doing similar things for years. For example, when you embed a COM object into a document, then double click that object to open it for editing, you can open it one of two ways. The application that supplied that content can supply a DLL that does the processing inside the hosting application. Alternatively, you can get in-place activation, where the application that supplied the embedded content gets opened inside of the hosting application. It usually adds its own menu entries to the menus, and takes over the display area.

Getting in-place activation to work well is hard, because it requires cooperation between applications that are mostly oblivious to each other. In the case of something like Chrome, however, the processes involved are all developed together, and have intimate knowledge of how each other work and such, so doing it shouldn't be nearly as complex.

I should add that I haven't really looked hard at Chrome, so I'm not sure this is how it really works. I'm just pointing out that it is definitely possible, and quite a few of us did it years ago. It's not as big of a deal now, but I'm pretty sure the OS should still support it all.