-
-
Notifications
You must be signed in to change notification settings - Fork 416
Fix Airspace issue #296
Comments
https://github.com/kolorowezworki/Airhack |
Thanks for providing a workaround! I'll keep this open until this is fixed or considered as an acceptable solution (I'd prefer the first option) |
We cannot fix airspace. Maybe we can fix VLC control, but not general problem with Winforms. This is caused by the method of rendering WPF and Winforms controls and windows. I think, at the moment, we can base only on workarounds. |
This could be fixed by #249 : If there is no reference to winforms, then there is no airspace issue, am I wrong? the option I'm thinking of is using DirectX to do the rendering, rather than using WinForm/HWND. vlc-winrt is already using that technique for win10 apps |
Sure. No Winforms/Win32Api == no airspace. DirectX is rendered the similar way to WPF. Avoiding problem is avoid, not solve ;) #249 is not about fixing airspace, rather about making something very new and different of current solution. We can use HWND of WPF Window directly and it will not need a reference to Windows.Forms, but airspace effect will not disappear. My workaround is for general mixing Winforms and WPF, not only for Vlc.DotNet control ;) |
A comment in #257 shows a workaround for the Airspace issue in stackoverflow : https://stackoverflow.com/questions/5978917/render-wpf-control-on-top-of-windowsformshost/23662410#23662410 |
A powerful workaround https://stackoverflow.com/a/43695349/1576027
|
Will be solved in 3.0.0 when #365 gets merged |
Should be fixed in 3.0.0-develop250 |
Many users have reported Airspace issues while using this library. One issue to rule them all and in the darkness bind them.
Sample code (taken from #41):
Technical explanations:
Following issues are impacted (and will be closed):
Proposed workarounds/hacks (untested):
The text was updated successfully, but these errors were encountered: