Hosting external app in WPF window

Question

We are developing a layout manager in WPF that has viewports which can be moved/resized/etc by a user. Viewports are normally filled with data (pictures/movies/etc) via providers that are under our control in the layout manager. My job is to examine if its also possible to host any external Windows app (i.e. notepad, calc, adobe reader, etc) in a viewport. I encounter a number of problems.

Most resources point to using the HwndHost class. I am experimenting with this walkthrough from Microsoft itself: http://msdn.microsoft.com/en-us/library/ms752055.aspx

I've adapted this so the list box is replaced with the windows handle from the external application. Can anybody help me out with these questions:

1. The walkthrough adds an extra static sub window in which the ListBox is placed. I don't think I need that for external apps. If I ommit it, I have to make the external app a child window (using Get/SetWindowLong from user32.dll to set GWL_STYLE as WS_CHILD). But if I do that, the menu bar of the app dissapears (because of the WS_CHILD style) and it no longer receives input.
2. If I do use the sub window, and make the external app a child of that things work reasonably, but sometimes the external app does not paint ok.
3. Also, I need the child window to resize to the viewport. Is this possible?
4. When the exernal app spawns a child window (i.e. Notepad->Help->About), this window is not hosted by the HwndHost (and thus can be moved outside the viewport). Is there any way I can prevent that?
5. Since I need no further interaction between the external application and the layout manager, am I right in assuming I do not need to catch and forward messages? (the walkthrough adds a HwndSourceHook to the sub window to catch selection changes in the listbox).
6. When you run the (unmodified) example VS2010 and close the window, VS2010 does not see that the program ended. If you break-all, you end up in assembly without source. Something smelly is going on, but I cannot find it.
7. The walkthrough itself seems to be very sloppy coded, but I have not found any better documentation on this subject. Any other examples?
8. Another approach is not to use HwndHost but WindowsFormHost as discussed here. It works (and is much simpler!) but I do not have control over the size of the application? Also, WinFormHost is not really meant for this?

Thanks for any pointers in the right direction.

Answer 1

Well... if the question had been posed like 20 years ago, one would have answer, "Sure, look at 'OLE'!", here is a link to what is "Object Linking and Embedding":

http://en.wikipedia.org/wiki/Object_Linking_and_Embedding

If you read this article, you will see the number of interfaces this spec defined, not because its author thought it was fun, but because it's technically difficult to achieve in the general cases

It's actually still supported by some apps (mostly Microsoft ones, as Microsoft was almost the only sponsor of OLE...)

You can embed these apps using something called DSOFramer (see links here on SO: MS KB311765 and DsoFramer are missing from MS site), a component that allows you to host OLE server (ie: external apps running as another process) visually inside an application. It's some kind of a big hack Microsoft let out a few years ago, that is not supported anymore to the point that the binaries are quite difficult to find!

It (may) still works for simple OLE servers, but I think I read somewhere it does not even work for new Microsoft applications such as Word 2010. So, you can use DSOFramer for application that support it. You can try it.

For others applications, well, today, in the modern world we live in, you don't host applications, ran in external process, you host components, and they are in general supposed to run inprocess. That's why you will have great difficulties to do what you want to do in general. One problem you will face (and not the least with recent versions of Windows) is security: how can your process I don't trust can legitimately handle my windows and menus created by my process :-) ?

Still, you can do quite a lot application by application, using various Windows hack. SetParent is basically the mother of all hacks :-)

Here is a piece of code that extends the sample you point, adding automatic resize, and the removal of the caption box. It demonstrates how to implicitely remove the control box, the system menu, as an example:

public partial class Window1 : Window {     private System.Windows.Forms.Panel _panel;     private Process _process;      public Window1()     {         InitializeComponent();         _panel = new System.Windows.Forms.Panel();         windowsFormsHost1.Child = _panel;     }      [DllImport("user32.dll")]     private static extern int SetWindowLong(IntPtr hWnd, int nIndex, int dwNewLong);      [DllImport("user32.dll", SetLastError = true)]     private static extern int GetWindowLong(IntPtr hWnd, int nIndex);      [DllImport("user32")]     private static extern IntPtr SetParent(IntPtr hWnd, IntPtr hWndParent);      [DllImport("user32")]     private static extern bool SetWindowPos(IntPtr hWnd, IntPtr hWndInsertAfter, int X, int Y, int cx, int cy, int uFlags);      private const int SWP_NOZORDER = 0x0004;     private const int SWP_NOACTIVATE = 0x0010;     private const int GWL_STYLE = -16;     private const int WS_CAPTION = 0x00C00000;     private const int WS_THICKFRAME = 0x00040000;      private void button1_Click(object sender, RoutedEventArgs e)     {         button1.Visibility = Visibility.Hidden;         ProcessStartInfo psi = new ProcessStartInfo("notepad.exe");         _process = Process.Start(psi);         _process.WaitForInputIdle();         SetParent(_process.MainWindowHandle, _panel.Handle);          // remove control box         int style = GetWindowLong(_process.MainWindowHandle, GWL_STYLE);         style = style & ~WS_CAPTION & ~WS_THICKFRAME;         SetWindowLong(_process.MainWindowHandle, GWL_STYLE, style);          // resize embedded application & refresh         ResizeEmbeddedApp();     }      protected override void OnClosing(System.ComponentModel.CancelEventArgs e)     {         base.OnClosing(e);         if (_process != null)         {             _process.Refresh();             _process.Close();         }     }      private void ResizeEmbeddedApp()     {         if (_process == null)             return;          SetWindowPos(_process.MainWindowHandle, IntPtr.Zero, 0, 0, (int)_panel.ClientSize.Width, (int)_panel.ClientSize.Height, SWP_NOZORDER | SWP_NOACTIVATE);     }      protected override Size MeasureOverride(Size availableSize)     {         Size size = base.MeasureOverride(availableSize);         ResizeEmbeddedApp();         return size;     } } 

This is basically all Windows "traditional" hacks. You could also remove item menus you don't like, as explained here: http://support.microsoft.com/kb/110393/en-us (How to Remove Menu Items from a Form's Control-Menu Box).

You can also replace "notepad.exe" by "winword.exe" and it seems to work. But there are limitations to this (keyboard, mouse, focus, etc.).

Good luck!

Answer 2

Simon Mourier's answer is extremely well written. However, when I tried it with a winform app made by myself, it failed.

_process.WaitForInputIdle(); 

can be replaced by

while (_process.MainWindowHandle==IntPtr.Zero)             {                 Thread.Sleep(1);             } 

and everything goes smoothly.

Thank you for the great question and all of you for your answers.