-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WPF and Win32 interop: 'Airspace' issue #152
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. |
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.
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. |
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
The text was updated successfully, but these errors were encountered: