Is there any property should be set when use WebView2 in Standard MDI?

Docking/MDI for WPF Forum

Posted 2 years ago by Yuki
Version: 22.1.3
Avatar

Hello,

I want to use WebView2 control in Standard-MDI.

Is there any property should be set when use WebView2 in Standard MDI?

WebView2 is always displayed in front of other document window.

I tried with "StandardMdiOnly" sample.

I replaced content of Document2.txt to WebView2 control.

<sampleBrowser:ProductItemControl
    ...
    xmlns:wv2="clr-namespace:Microsoft.Web.WebView2.Wpf;assembly=Microsoft.Web.WebView2.Wpf">

...

<docking:DocumentWindow
    Title="Document2.txt"
    Description="Text document"
    FileName="Document2.txt"
    ImageSource="/Images/Icons/TextDocument16.png">
    <wv2:WebView2 docking:InteropFocusTracking.IsEnabled="True" Source="https://docs.microsoft.com/en-us/" />
    <!--<TextBox BorderThickness="0" Text="The second document." TextWrapping="Wrap" />-->
</docking:DocumentWindow>

Comments (5)

Posted 2 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hello,

WebView2 is an interop control and therefore suffers the commonly-known airspace issue in WPF, as do other controls that use HwndHost.  They always render their content on top of any WPF content in the same Window.  This is an issue with the core WPF framework and is nothing we can control.

Since standard MDI windows can overlap each other, they cannot be used if your app has interop controls due to the airspace issue.  You should use tabbed MDI instead if you have interop controls in your application.  Tabbed MDI doesn't overlap controls and thus never encounters the airspace issue.


Actipro Software Support

Posted 2 years ago by Yasuhiro Gotou
Avatar

Hello,

Thanks for your response.

We have two additional questions.

  1. Tabbed MDI windows can also overlap each other in the tabbed area. When the webview is behind the tab area, why does not the webview render on top?
  2. Can the standard MDI problem be solved by consuming more time? Or is it impossible to solve for technical reasons?

[Modified 2 years ago]

Posted 2 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hello,

1) Tabbed MDI only shows the selected tab's content at any given time.  Therefore unselected tabs aren't rendering interop controls and avoid any interop controls in their content from appearing above the selected tab's content.  That's why tabbed MDI doesn't experience the airspace issue.

2) No, unfortunately it's a core problem in WPF that has existed since the beginning and only Microsoft can solve it.  The core issue is nothing related to our controls and can easily be reproduced without our controls.


Actipro Software Support

Posted 2 years ago by Yuki
Avatar

Hello,

2) No, unfortunately it's a core problem in WPF that has existed since the beginning and only Microsoft can solve it.  The core issue is nothing related to our controls and can easily be reproduced without our controls.

There are some workaround for this issue.

Will these workaround solve this issue?

I tried add above workaround to content of DocumentWindow.

However, the issue was not solved.

I guess it is necessary to add it in DockSite or other library.

[Modified 2 years ago]

Posted 2 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

The only way to work around the problem in general is to wrap certain content in another Win32 window of its own, with its own window handle.  I believe that's likely what those airspace workarounds are doing behind the scenes. 

If you tried to do it for standard MDI, you would most likely have to put one of those adorners in the root of the StandardMdiWindowControl control's Template.  You do this by cloning our default Template for the control and making an implicit Style in your App.Resources that target the control Type and has the altered Template set.  That might get the StandardMdiWindowControl instances to overlap each other.  Then you'd also need to do the same for the StandardMdiHost control's Template so that any standard MDI windows that extend past the visible bounds of the StandardMdiHost get clipped.

Note that even if the airspace problem is worked around by doing those things, there might be other new routed event, focus, etc. issues introduced, so you will have to really test and make sure everything still works properly.


Actipro Software Support

The latest build of this product (v24.1.3) was released 2 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.