在关闭第一个子虚拟机之后，显示一个子虚拟机，然后显示另一个 [英] Show one child VM, then show another, after the first was closed

问题描述

我有一位家长指挥。我想显示其中的第一个视图模型。然后在第一个关闭后（即完成一些操作），我想显示一个不同的视图模型。

I have one parent conductor. I want to show first view-model inside it. Then after first one is closed (i.e. some operation is done), I want to show a different view-model.

我正在使用 Caliburn.Micro.Contrib ，其中 ConductResult 显示子级导体中的虚拟机。它有一个很酷的扩展方法 AfterClosingDo ，该方法在停用并关闭该孩子后运行协程。

I'm using Caliburn.Micro.Contrib, where a ConductResult displays child VM in a Conductor. It has a cool extension method AfterClosingDo, which runs a coroutine after that child was deactivated and closed.

但是，当我使用 AfterClosingDo ，基本上发生这种情况：

However, when I run another ConductResult using AfterClosingDo, basically this happens:

• 第一个子VM已关闭


• 发生停用事件，ConductResult运行AfterClosing操作


• 在AfterClosing中，我在父Conductor中使用ConductResult打开第二个子VM


• 第二个子VM已正确激活


• 但是，第一个子VM的停用仍然没有完成，并且 null 项在Conductor中设置为活动 li>
  

• first child VM is closed
• Deactivated event occurs, ConductResult runs AfterClosing action
• in AfterClosing, I open second child VM using ConductResult in parent Conductor
• second child VM is properly activated
• however, the deactivation of first child VM still isn't completed, and null item is set as active in the Conductor

第一个VM基本显示了加载操作的进度，第二个VM显示了实际数据。加载完成后，我想在父Conductor中显示数据（当然使用第二个VM）。

First VM basically shows progress of a load operation, second VM shows actual data. After the load is complete, I want to show the data in parent Conductor (using second VM, of course).

所以，我的问题是：有一种干净的方法可以在 Caliburn.Micro 中做到这一点，最好不要覆盖导体，屏幕等的默认行为。

So, my question: is there a clean way to do this in Caliburn.Micro, preferably by not overriding default behavior of Conductor, Screen, etc.

考虑使用 EventAggregator ，尽管我不确定是否是最好的解决方案。

I was thinking of using EventAggregator, though I'm not sure, if it's the best solution.

推荐答案

我遇到了一个非常类似的问题，即我有一个指挥打开一个子VM，然后弹出一个确认框，提示您要关闭吗，并为原始项目 CanClose触发了回调方法具有与您描述的效果相同的效果。

I had a very similar issue where I had a conductor opening a child VM, then a confirmation box would pop-up saying "do you want to close" and had fired a callback for the original items CanClose method which had the same sort of effect as you described.

弹出窗口VM将关闭，但在关闭时将触发应关闭第一个VM的回调。

The popup VM would close, but in closing it would fire a callback which was supposed to close the first VM.

我的指挥最终重新激活了令人讨厌的原始VM。事件的顺序为：

My conductor ended up re-activating the original VM which was annoying. The order of events was:

• 打开VM 1


• 尝试关闭VM 1


• 已触发CanClose保护方法


• 在VM 1的CanClose中弹出VM 2（使用同一导体）


• 在VM上确认按钮单击2。


• 确认按钮触发CanClose回调并关闭VM1


• VM2关闭


• 导体记得虚拟机1在虚拟机2之前处于活动状态，因此在关闭虚拟机1之后重新打开

• Open VM 1
• Try Close VM 1
• CanClose guard method fired
• Popup VM 2 (using same conductor) in CanClose of VM 1
• Confirm button on VM 2 is clicked
• Confirm button fires callback for CanClose and closes VM1
• VM2 Closes
• Conductor remembers that VM 1 was active before VM 2 so re-opens VM 1 after it's closed

最后，我只是实现了一个接口，

In the end I just implemented an interface which fired after the close.

子项在关闭后需要执行的工作实现了接口（ IAfterClose ）

Child items which have work to do after they have closed implement the interface (IAfterClose)

然后我在导体上为 DeactivateItem 提供了覆盖：

Then I provided an override for DeactivateItem on the conductor:

    public override void DeactivateItem(IScreen item, bool close)
    {
        var afterClose = item as IAfterClose;

        base.DeactivateItem(item, close);

        if (afterClose != null && close)
            afterClose.AfterClose();
    }

这可以确保回调未过早触发。不知道这是否会使您受益（因为我没有使用contrib库），但是它可能会给您一些想法。

This made sure that the callback wasn't fired too early. Not sure if this will benefit you (since I've not used the contrib library) but it might give you some ideas.

唯一的缺点是我有对 DefaultCloseStrategy 进行修复，因为当回调将触发时，它将在其中引发空引用异常。我应用的修复程序似乎不会造成任何不良影响，但是我还没有真正研究过为什么会引发null ref异常。

The only downside to this was that I had to make a fix to DefaultCloseStrategy as when the callback would fire it would throw a null reference exception in there. The fix I applied seemed to cause no ill-effect but I've not really looked at why the null ref exception was thrown.

我找不到其他方法自从上次触发的事件似乎是停用事件以来，便开始执行此操作，但它们仍为早期。

I couldn't find any other way to do this since the last event that fires seems to be the deactivation events and they are still to early.

这篇关于在关闭第一个子虚拟机之后，显示一个子虚拟机，然后显示另一个的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！