Home > Net >  In ReactiveUI the same code behaves differently depending on how observable is subscribed
In ReactiveUI the same code behaves differently depending on how observable is subscribed

Time:06-14

The code:

            StartOperation = ReactiveCommand.CreateFromObservable(() => Observable.Start(() =>
            {
                    SelectedOperation.State = OperationState.ACTIVE.ToString();
                    checkboxService.SaveChanges();
            }));

results in binding handlers in being invoked seemingly randomly, whereas:

            StartOperation = ReactiveCommand.Create(() =>
            {
                Interactions.Confirm.Handle(new MessageBoxArguments { CanCancel = false, IsWarning = false, Message = "Operation started!", Title = "Success" }).Subscribe(x =>
                {
                    SelectedOperation.State = OperationState.ACTIVE.ToString();
                    checkboxService.SaveChanges();
                });
            });

Works perfectly. I assume this is to due with scheduling, but I would have thought that in both cases the code would be scheduled to run in the same way, except in the second example, a message box is shown first. Maybe the delay makes things work correctly?

The project is Winforms (I know) on .Net Standard and ReactiveUI is 17.1.50.

I would be very happy for some pointers here!

CodePudding user response:

So it turns out that the reason it worked in the second example was not because of scheduling, but rather because showing the MessageBox, forced the UI to update events.

The reason this is needed, is because the button triggering StartOperation, is also affected by SelectedOperation.State being updated (the Enabled property is dependent on this) and it seems the flow is like this:

  1. Clicking triggers StartOperation (OnClick)
  2. This then updates SelectedOperation.State
  3. This triggers various bindings, finally leading to an update of the Enabled property
  4. This is not working well/predictably, because the button is in some kind of transition state firing events and so on.

The solution in short, is to make sure that Application.DoEvents() is called somewhere in that chain, forcing the button out of whatever state it's in.

  • Related