Wpf: WPF and Win32 interop: 'Airspace' issue
If you've ever had to host any WinForms forms inside a WPF project, you might know about the 'Airspace' problem. Basically, the WinForms control must always be on top. It would be great if you consider to solve the 'Airspace' issue
https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanced/wpf-and-win32-interoperation
https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanced/technology-regions-overview
pavelovcharov
All 2 comments
As explained by your second link this constraint comes from mixing different technologies on the window manager level and is not a WPF implementation decision. Other frameworks have the same problem when they want to mix with different technologies.
Note that WinForms does not always have to be on the top, you can use HwndSource/HwndHost pairs in strategic places to put WPF content over WinForms (or other technologies) content. This can be used for example to implement docking panels like Visual Studio has, which can freely mix WPF and WinForms based panels. I've also used it in the past to use SharpDX to render directly to a HWND (instead of low performance D3DImage) and still put WPF content on top of it.
That said, the airspace situation could be improved by adding support for newer technologies to WPF, in particular the window manager now supports composition of multiple content layers and integration of swap chains which is both not directly accessible through WPF yet. This won't fix the airspace issue but it would give you more tools to work around it.
weltkante
on 11 Dec 2018
No only the airspace happens in the WinForms, but also it happens in the XAML Island.
In this thread, they talk about extensible rendering pipeline. https://github.com/dotnet/wpf/issues/85
And I hope the win2d can bring to WPF https://github.com/dotnet/wpf/issues/97
lindexi
on 11 Dec 2018
Related issues
h82258652
路
3Comments
guytp
路
3Comments
Pzixel
路
3Comments
lisberPontes
路
3Comments
Normandy
路
3Comments
Most helpful comment
As explained by your second link this constraint comes from mixing different technologies on the window manager level and is not a WPF implementation decision. Other frameworks have the same problem when they want to mix with different technologies.
Note that WinForms does not always have to be on the top, you can use HwndSource/HwndHost pairs in strategic places to put WPF content over WinForms (or other technologies) content. This can be used for example to implement docking panels like Visual Studio has, which can freely mix WPF and WinForms based panels. I've also used it in the past to use SharpDX to render directly to a HWND (instead of low performance D3DImage) and still put WPF content on top of it.
That said, the airspace situation could be improved by adding support for newer technologies to WPF, in particular the window manager now supports composition of multiple content layers and integration of swap chains which is both not directly accessible through WPF yet. This won't fix the airspace issue but it would give you more tools to work around it.