This is possible due to Win32 SetParent's capability to allow a Win32 Window/Control to have a parent from a different process (see first examples of this technique in action in: IBM AppScan Source's and AppScan Standard's TreeViews running side-by-site in the same GUI and in Injecting a .NET REPL into an Unmanaged/C++ application (Notepad)
You can download the 1 Mb tool from: Util - Win32 Window Handle Hijack (simple) v1.0.exe
Quick tour of this tool's capabilities.
After opening the tool, the first GUI looks like this:
For example, in the image below a Windows Explorer File list was chosen (from the explorer.exe process)
After clicking on the Hijack link, the Windows Explorer File is now going to 'exist' inside the Util - Win32 Window Handle Hijack (simple) v1.0 .Net App
The Restore link, will reset the hijacked Window/Control to its original parent (in this case the explorer.exe process)
Clicking the Hijack link will set the ListBox parent to be the panel inside the app on the right (running on a different process)
Note that the hijacked control is fully functional (with events correctly handled).
In the image below, the TreeView was expanded, with any event/actions triggered occurring on the original parent (to the left) .
Basically the Hijacked TreeView still thinks that it is on the correct process and location)