Replies: 3 comments 2 replies
-
|
I'm even more confused that I created a small project to reproduce the problem and everything works fine there 🤨 |
Beta Was this translation helpful? Give feedback.
-
|
What might be useful if you can tell me the class type from the debugger for your schedulers |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I'm dumb (or we'll say overworked, it sounds better). When I started upgrading, I tried putting the builder in my ViewModelLocator which configures my dependencies injection through the Splat.DependencyInjection.SourceGenerator (yeah, I should upgrade from that too, but DI in the builder seems to miss some methods I'm using). As it wasn't working there, I set it like the example in the startup override, but forgot to remove it from the other class. Calling the builder twice is a bad idea! Sorry to have disturbed you. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello,
I'm a bit confused as I upgraded to the latest ReactiveUI version. I saw the library changes and didn't encounter any trouble for Avalonia project, simply replacing RxApp.MainThreadScheduler to RxSchedulers.MainThreadScheduler did the trick.
But now I'm running into some thread conflicts with WPF.
I do the configuration at startup:
My interaction is created as running on the main thread.
If my interaction registration is async, I will get an exception, even if I comment out any await instruction. It tells me the thread of the interaction is owning the UI element, but it should as it is created with RxSchedulers.MainThreadScheduler as parameter.
If I try to store the MainThreadScheduler from the result of the RxAppBuilder, it complains about not being STA.
I don't know what I'm missing 🤔
Beta Was this translation helpful? Give feedback.
All reactions