-
Notifications
You must be signed in to change notification settings - Fork 2.4k
- Why is so-and-so WinForms control inside the
WindowsFormsHostinvisible or not rendering? - Why is the
WebBrowser(or other control) covering myFlyout(or another control)? [AIRSPACE]
What you are facing is an issue colloquially called the Airspace issue. Due to the different underlying graphical engines used in WinForms (GDI) and WPF (DirectX and such), there are some interop issues. Sometimes, your controls appear will be invisible. Sometimes, your WinForms control may overlap your WPF controls.
It is important to know that this is an WPF issue, not a MahApps.Metro one.
By default, the vanilla Window class and MahApps.Metro's MetroWindow has AllowsTransparency set to false. If you set this in MahApps.Metro's MetroWindow initialized event to true you will get this issue.
The solution, should for some reason that you need AllowsTransparency to be set to true or get the rendering issue with WindowsFormsHost is:
- Go to https://microsoftdwayneneed.codeplex.com/ or now on GitHub here or here
- Get (compile) the lib and add it as a reference to your project.
- Add
xmlns:interop="clr-namespace:Microsoft.DwayneNeed.Interop;assembly=Microsoft.DwayneNeed"to your XAML. - Place your Control in the
AirspaceDecorator:
<interop:AirspaceDecorator AirspaceMode="Redirect"
Background="White"
IsInputRedirectionEnabled="True"
IsOutputRedirectionEnabled="True">
<!--your winforms control or webbrowser here here-->
</interop:AirspaceDecorator>
thanks to @myCollections for providing this screenshot from #1038
Chances are
- your
WebBrowseris being moved by theMetroWindow's built-inTransitioningContentControl.
The solution for the issue is to set the WindowTransitionsEnabled property on your MetroWindow to false (or use the AirspaceDecorator explained above).
Take a look to this blog post with a nice explanation why this happens.
Simply wrap your TextBox (or the complete container) in an AdornerDecorator.
The short answer is you can't, unless you use ShowModalDialogExternally.
The long answer is because internal dialogs (dialogs shown inside of a MetroWindow) are not real dialogs. They are controls shown on top of your MetroWindow's content. That means that it requires that the UI thread/dispatcher be available to work, just like your controls do.
We use internal dialogs asynchronously so that you can wait for a response from the dialog and keep the UI available for other potential user interactions.
The reason that external dialogs can be used synchronously is because since the dialog has it's own "window", it has its own UI thread that can wait for user input.
Full MahApps documentation is available at https://mahapps.com
