17

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:

  • When my window gains input focus, the main application window of the external process loses focus (i.e. title bar changes color)
  • Keyboard shortcut commands of the main application do not work while my window has focus

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

halfer
  • 19,824
  • 17
  • 99
  • 186
flashk
  • 2,451
  • 2
  • 20
  • 31
  • The issue here aren't those *"few problems"* you know about. The real issue are the problems you don't even know about. In short: This cannot safely be done. See [Is it legal to have a cross-process parent/child or owner/owned window relationship?](https://blogs.msdn.microsoft.com/oldnewthing/20130412-00/?p=4683) for rationale. – IInspectable Jul 08 '18 at 11:52

3 Answers3

11

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.

flashk
  • 2,451
  • 2
  • 20
  • 31
  • 1
    That's not the solution. Calling `SetParent` calls `AttachThreadInput` implicitly. Explicitly calling it again does't change anything (unless your call to `SetParent` failed for other reasons). – IInspectable Jul 08 '18 at 11:54
4

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.

Stephen
  • 41
  • 1
2

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

Anthony Ho
  • 121
  • 6