search

reactiveui / ReactiveUI

An advanced, composable, functional reactive model-view-viewmodel framework for all .NET platforms that is inspired by functional reactive programming. ReactiveUI allows you to abstract mutable state away from your user interfaces, express the idea around a feature in one readable place and improve the testability of your application.
https://www.reactiveui.net
MIT License
8.05k stars 1.12k forks source link

[Bug]: Mixing WPF and WinForms packages (`ElementHost`ing WPF controls inside WinForms) breaks MainThreadScheduler (and possibly other things) #3886

Open Metadorius opened 4 weeks ago

Metadorius commented 4 weeks ago

Describe the bug 🐞

WaitForDispatcherScheduler silently breaks because apparently the dispatcher is either not created at all or not created before ElementHost appears. As a result all my .ObserveOn(RxApp.MainThreadScheduler) calls don't actually do anything.

Apparently there are also per-platform registrations that may clash, but I haven't observed the results yet.

Step to reproduce

  1. Install ReactiveUI.WinForms and ReactiveUI.WPF
  2. Create a WinForms app
  3. Try to use .ObserveOn(RxApp.MainThreadScheduler) to switch threads

Reproduction repository

No response

Expected behavior

All should happen as normal

Screenshots 🖼️

No response

IDE

No response

Operating system

No response

Version

No response

Device

No response

ReactiveUI Version

20.1.1

Additional information ℹ️

Using net48

ChrisPulman commented 4 weeks ago

Interesting scenario I will take a look at the possibilities here, understanding that the wpf section needs to run on the wpf ui thread, but as it's a Winforms application so it will need to register the Winforms scheduler and the Winforms sections will need this thread, obviously we can't have two threads set as the MainThreadScheduler. I assume that the application uses a small amount of Wpf and is the majority Winforms.

Metadorius commented 4 weeks ago

It is indeed WinForms in the majority currently, but we're intending to phase out WinForms eventually so we started to introduce separate pages built using WPF.

Maybe as a quick fix accounting for the order of registrations would help? #3887

Metadorius commented 4 weeks ago

BTW I just tested reversed registration order for WinForms and WPF registrations, and in my case MainThreadScheduler unbroke. Apparently WinForms one doesn't outright break when used in WPF because it seems to function fine so far on the basic level.