Giters

dotnet / wpf

WPF is a .NET Core UI framework for building Windows desktop applications.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

WPF and Win32 interop: 'Airspace' issue

pavelovcharov opened this issue · comments

commented

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

commented

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.

commented

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. #85

And I hope the win2d can bring to WPF #97

commented

In as respectful a manner as is possible I would like to note that it looks like Microsoft has zero intentions of ever fixing this issue, as even noted by Microsoft Employee @champnic in This Issue.

WPF is not going to make those changes at this point, so we are going to have to make changes on the WebView2 side

I cannot begin to express my frustrations after having to come up with ridiculous solutions to this problem multiple times. Requiring absolutely ludicrous application architecture.

Please, in a respectful manner as is possible. Fix this.

If you indeed have zero intentions of fixing the issue. Please Close this so that the community knows with no ambiguity.