-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[BUG] UWP - SingleWindowDispatcherScheduler causes issues in XamlIsland #2154
Comments
Hey @jasonwurzel 👋, Thank you for opening an issue. We will get back to you as soon as we can. Also, check out our Open Collective and consider contributing financially. https://opencollective.com/reactiveui
|
I'll have a look on the weekend anyway. I would like to get this solved for rxui 10 release |
That's great! Maybe I'll have an answer until then from windows-toolkit ( CommunityToolkit/Microsoft.Toolkit.Win32#174 ) |
Alexandre was swift to answer my issue on windows-toolkit, see here for his answer. |
Well. All the platform registrations do is add registrations to splat so potentially you can add your own registration and override the rxui with your own worse case. I will see about doing that fix for the weekend regardless. |
Hey Glenn, On another note: Shouldn't it be possible to register the MainThreadScheduler in DI so anyone can override it (using the given |
@RLittlesII is replacing the init to work much closer to the way a lot of Microsoft init works for Rx 11. The issue with the current approach is it's expensive to use reflection for all loaded assemblies which that change would require. |
I think this is fixed by #2215 |
After being on RxUI 9.13.1 for a while (the last version without SingleWindowDispatcherScheduler), I have some time to finally look into this again. Unfortunately it isn't fixed by #2215 . The reason is that in the XamlIsland case, any access to the CoreApplication.Views collection throws an exception. (be it Views[0] or Views.FirstOrDefault()). #2215 did not replace the logic in the constructor, so the exception is still raised (Views.Count > 0 yields true, yet accessing Views[0] throws). Ah, the wonders of XamlIslands... I'm a bit hesitant to fix it. Basically, my fix would be to fall back to using the old logic for uap, directly setting CoreDispatcherScheduler.Current, relying on some mechanism to detect we are inside a XamlIsland. In the worst case this would be a boolean flag somewhere (RxApp). |
@RLittlesII is going through some real life stuff at the moment so might be best if we can fix it now. |
type: fix accessing CoreApplication.Views throws in XamlIslands, thus in this case get the CoreDispatcher by alternate means issue: #2154
I pushed out a release with your change in it this morning. Thanks :) |
yes, thank you very much for the fast release, already testing 👍 |
Describe the bug
My UWP project lives inside a XamlIsland, that is, I have a WPF application having a WindowsXamlHost that in turn hosts a UWP control. Since #2100 any access to RxApp.MainThreadScheduler results in an Exception.
The root cause is that in the newly introduced
SingleWindowDispatcherScheduler
the dispatcher is fetched viaCoreApplication.Views[0].Dispatcher
, but this is not present inside the XamlIsland Context.CoreApplication.Views.Count
is > 0, but subsequently accessing.Dispatcher
results in an Exception.Steps To Reproduce
see https://github.com/jasonwurzel/XamlIslandDispatcherProblem for a repo. Start either ControlPlaygroundPackage (WPF - XamlIsland - Uwp) or UwpApp (UWP App) (in Debug - x64). Starting UwpApp results in no exception, starting the WPF App results in an exception when CoreApplication.Views[0].Dispatcher is accessed.
Expected behavior
Accessing
RxApp.MainThreadScheduler
should not result in an exception. If it is correct that the Views in the Views enumeration have no dispatcher in the XamlIsland case, we have to find a workaround in that special case.Additional context
I'm not sure whether the views in the Views enumeration should have a Dispatcher present or not. I'll check with the Windows.Toolkit guys as well.
For simplicity's sake I ommitted referencing the actual ReactiveUI package in my repro (XamlIslands with 3rd party nuget references is still uncharted territory, unfortunately and requires some - more - fiddling with the csproj files.)
The text was updated successfully, but these errors were encountered: