CODEWITHSUNDEEP
c#wpfcaliburn.micro
croxy
croxy

Reputation: 4178

Screen does not close even though Caliburn says it's deactivated and closed

When tyring to close a Screen (MyViewModel) itself with this.TryClose() Caliburn logs that it gets deactivated and closed:

Caliburn INFO: [2016-12-12T14:43:05.4275321+01:00] Deactivating MyViewModel.

Caliburn INFO: [2016-12-12T14:43:05.4275321+01:00] Closed MyViewModel.

But the Screen does not close. It's still there and I even can interact with the buttons on it.

The Screen is activated inside a conductor class:

public class ShellViewModel : Conductor<Screen>.Collection.OneActive
{
    // [...]
    ChangeActiveItem(new MyViewModel(), false);
    // [...]
}

When I now try to close the active Screen (which is at this point the MyViewModel) from the conductor class with:

ActiveItem.TryClose();

It gets closed properly.

So How is it possible that the Screen does not get closed when using this.TryClose() inside its class, even though Caliburn says it is closing the Screen. But it gets closed properly when trying to close it from the conductor class?
Funny is that I have another ViewModel with the exact same code and there it works as expected.

Note:
Inside the MyViewModel class I call the this.TryClose() in the OnActivate() method:

protected override void OnActivate()
{
   base.OnActivate();
   // do some stuff
   this.TryClose();
}

So basically the screen should pop up and close instantly.

Another Note:
When I try calling ActiveItem.TryClose() in the conductor after calling the this.TryClose() in MyViewModel the call in the conductor stops working too, with the logging message from Caliburn:

Caliburn INFO: [2016-12-12T14:57:11.9553219+01:00] TryClose requires a parent IConductor or a view with a Close method or IsOpen property.

Upvotes: 0

Views: 743

Answers (1)

croxy
croxy

Reputation: 4178

Apparently it seems that the this.TryClose() call comes in too fast after activating the Screen. When putting a Task.Delay(50) before the TryClose() call it works just fine.
The reason that it worked in the other ViewModel with the same code is that there the code needs a bit more time to execute.

Still don't know the exact reason why Caliburn acts like that.

Upvotes: 1

Related Questions