1

In the WPF application we are hosting third party application(Win32) using WindowsFormsHost control by setting a parent for the main window of that third party application. Sample Code: 

<telerikDocking:RadPaneGroup>
    <telerikDocking:RadDocumentPane>
        <Grid>
            <WindowsFormsHost x:Name="windowFormHost">
                <wf:Panel x:Name="TestPanel"/>
            </WindowsFormsHost>
        </Grid>
    </telerikDocking:RadDocumentPane>
</telerikDocking:RadPaneGroup>

On loading of this control, the Panel will be set as a parent for the Main window of the third party application. This is done using Windows Native Methods.

public static extern IntPtr SetParent(IntPtr hWndChild, IntPtr hWndNewParent);

Parent handle is the TestPanel.Handle and the child handle is Process.MainWindowHandle of the third party application.

Issue 1: Now when any action is performed from the WPF application window on the third party application (using the api's provided by it), it will show a progress bar which is a modal dialog to it. When this happens, the focus is shifted to that progress dialog and after the progress dialog is closed, the WPF window goes behind the previously activated window. It could be another window of the WPF application or could be even a notepad window.

As per msdn https://learn.microsoft.com/en-us/dotnet/api/system.windows.window.showdialog?redirectedfrom=MSDN&view=netframework-4.8#System_Windows_Window_ShowDialog. "When a modal WPF window (a window opened by calling ShowDialog) is closed, the previously activated window is reactivated. If a modal WPF window has an owner window (see Owner), the owner window is not reactivated when the modal WPF window is closed unless it was the previously activated window."

Workaround: Hooking on to the third party application windows and if it launches any child windows, set the focus on that window so that it becomes foreground window.

Any other better way of handling this?

Issue 2: It gets even more complicated if the WPF window (which is currently hosting the third party window) shows a modal window and any action on this modal window results in a child window of the third party main window. If the child window appears and disappears even before it could be processed(to set the focus on it and make it foreground), then the first workaround doesn't work.

Need inputs to handle this gracefully or in any better way possible.

Adrian Mole
  • 49,934
  • 160
  • 51
  • 83
DevMindzz
  • 21
  • 4
  • 1
    SetParent is the supreme Windows hack, you're lucky it "works" and doesn't simply crash the window you change the parent of. When I write some app, I don't expect anyone to parent my Window(s). One function you must add to your toolbox though is AllowSetForegroundWindow https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-allowsetforegroundwindow with which one process allows another one to change the foreground window. It usually help fixing some issues. – Simon Mourier Jun 11 '20 at 14:41
  • I don't think AllowSetForegroundWindow will work for me. As the hooking of the third party application runs in a background process (without a window) which is responsible for managing the life time of the third party application. So i might run into – DevMindzz Jun 11 '20 at 15:59
  • AllowSetForegroundWindow exists exactly to allow using SetForegroundWindow between two completely different processes. That being said, it's very possible I don't understand exactly what's your problem is as it's not 100% clear when reading it IMHO. – Simon Mourier Jun 11 '20 at 16:32
  • @SimonMourier In case it is not clear. The main problem is, the WPF application window goes behind a previously activated window (another window from same wpf application or some other window like a notepad if i navigate from notepad to the wpf window which hosts the third party application window) when any other child window (modal or modeless) is displayed by the third party application window. Even though the wpf application's IsActive is true, it is still behind the previously activated window. Window hooking doesn't help if a modal dialog is shown by the wpf window. – DevMindzz Jun 11 '20 at 16:46
  • [You must first become the master of the rules before you can start breaking them.](https://devblogs.microsoft.com/oldnewthing/20130412-00/?p=4683) – IInspectable Jun 11 '20 at 16:54
  • Still not sure I fully understand :-/ Maybe my code here can help, I wrote it to activate a Window in another process, even if it has a modal dialog open: https://stackoverflow.com/a/16522305/403671 (look at ModalWindowUtil) – Simon Mourier Jun 11 '20 at 16:57
  • @IInspectable Yes, understood the complications during the development of this and had even gone through your extensive blogs about it, but couldn't find something similar to this issue. 'Master of rules' - Will get there someday :) – DevMindzz Jun 11 '20 at 17:16

0 Answers0