CODEWITHSUNDEEP
cwinapi
flashk
flashk

Reputation: 2493

Embedding HWND into external process using SetParent

I'm trying to embed a window from my process into the window of an external process using the SetParent function and have encountered a few problems. First off, here is an outline of what I am currently doing to embed my window into the application:

HWND myWindow; //Handle to my application window
HWND externalWindow; //Handle to external application window

SetParent(myWindow,externalWindow);

//Remove WS_POPUP style and add WS_CHILD style
DWORD style = GetWindowLong(myWindow,GWL_STYLE);
style = style & ~(WS_POPUP);
style = style | WS_CHILD;
SetWindowLong(myWindow,GWL_STYLE,style);

This code works and my window appears in the other application, but introduces the following issues:

Is there a workaround for this? I would like my window to be treated as just another child window of the main application.

Upvotes: 17

Views: 10972

Answers (3)

Anthony Ho
Anthony Ho

Reputation: 131

I ran into the same issue, after reading MSDN doc carefully, I found it an easy fix.

You should remove WS_POPUP and add WS_CHILD BEFORE you call setParent

It's stated in MSDN:

For compatibility reasons, SetParent does not modify the WS_CHILD or WS_POPUP window styles of the window whose parent is being changed. Therefore, if hWndNewParent is NULL, you should also clear the WS_CHILD bit and set the WS_POPUP style after calling SetParent. Conversely, if hWndNewParent is not NULL and the window was previously a child of the desktop, you should clear the WS_POPUP style and set the WS_CHILD style before calling SetParent.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms633541(v=vs.85).aspx

Upvotes: 3

Stephen
Stephen

Reputation: 41

I am not sure if you are still interested in this topic after almost three years. I am working on a similar application. My solution is to modify the window style before you call SetParent. With this solution, I don't have to call AttachThreadInput.

However, one major issue of hosting child windows from an external process is that if the external process hangs while responding to a user keyboard or mouse input, the main application also freezes. The message loop in the main application is still running. However, it no longer receives user input events. Therefore, it appears as if it is hanging. I believe that's the direct result of AttachThreadInput since the input events of the two threades are now synchronized. If one of them is blocked, both are blocked.

Upvotes: 4

flashk
flashk

Reputation: 2493

Well, I finally found the answer to my question.

To fix the issue with the main app losing focus you need to use the AttachThreadInput function to attach the embedded window thread to the main app thread.

Also, one can use the TranslateAccelerator function in response to WM_KEYDOWN messages to ensure accelerator messages of the main app are triggered.

Upvotes: 11

Related Questions