关闭时卸载子窗口(silverlight mvvm)

发布于 2024-11-26 11:10:30 字数 1026 浏览 0 评论 0原文

如何确保我的子窗口在关闭时被卸载?

我正在从我的视图模型中打开子窗口,但是在关闭它之后,它仍然会触发诸如组合框中的选择更改之类的事件。

子窗口使用与调用它相同的视图模型,所以我想这解释了事件被触发的原因。项目来源仍然有效。

但是当它关​​闭时,我想永久“处置”子窗口。

我尝试添加一个像这样的关闭处理程序(默认视图代码后面):

    private void OnLaunchEditItem(ItemMessage msg)
    {
        var editWnd = new EditItemWindow();
        editWnd.Closed += new EventHandler(editWnd_Closed);
        editWnd.Show();
    }

    void editWnd_Closed(object sender, EventArgs e)
    {
        sender = null;
    }

没有成功..

所以我现在要做的是从子窗口控件中删除itemssource,这在我看来......不是理想的解决方案问题。关闭时一定可以从内存中处理掉所有内容吗? (子窗口“查看”代码隐藏)

    private void OKButton_Click(object sender, RoutedEventArgs e)
    {
        this.DialogResult = true;
        combobox1.ItemsSource = null;
        combobox2.ItemsSource = null;
    }

    private void CancelButton_Click(object sender, RoutedEventArgs e)
    {
        this.DialogResult = false;
        combobox1.ItemsSource = null;
        combobox2.ItemsSource = null;
    }

How may I ensure that my childwindow is unloaded when it's closed?

I am opening the childwindow from my viewmodel, but after it's been closed it still fires of events like selectionchanged on comboboxes.

The childwindow is using the same viewmodel as it's been called from, so I guess that explains why the events are being fired. The itemssources are still valid.

But when it's closed, I would like to "dispose" the childwindow for good.

I've tried to add a Closed handler like this (Default view code behind):

    private void OnLaunchEditItem(ItemMessage msg)
    {
        var editWnd = new EditItemWindow();
        editWnd.Closed += new EventHandler(editWnd_Closed);
        editWnd.Show();
    }

    void editWnd_Closed(object sender, EventArgs e)
    {
        sender = null;
    }

No sucesss..

So what I'm doing now is to remove the itemssource from the childwindow controls, which seems to me... not the ideal solution to the problem. It must be possible to dispose it all from memory on closing? (Childwindow "view" code-behind)

    private void OKButton_Click(object sender, RoutedEventArgs e)
    {
        this.DialogResult = true;
        combobox1.ItemsSource = null;
        combobox2.ItemsSource = null;
    }

    private void CancelButton_Click(object sender, RoutedEventArgs e)
    {
        this.DialogResult = false;
        combobox1.ItemsSource = null;
        combobox2.ItemsSource = null;
    }

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

卷耳 2024-12-03 11:10:30

消息传递有一个已知问题,即它在消息发送者和消息接收者之间引入了硬链接。因此,如果您使用消息传递,则必须确保调用 Messenger.Unregister 方法。换句话说,当您调用注册来处理消息时,请确保您也调用取消注册

因此,在您看来,您必须注册Unloaded 事件;然后您可以调用 Messenger.Unregiser(this); 这是您的视图。

在 ViewModel 中,您必须确保调用 Cleanup 方法来取消注册 ViewModel 作为消息接收者。

另请参阅:

MVVM Light Listener未发布/ 注册对象的确定性终结?MVVM Light Messenger 执行多次

劳伦特意识到了这个问题,但到目前为止还没有解决方案。

The messaging has a known problem that it introduces a hard link between the messenger and the recipient of a message. So if you use messaging you havee to ensure that the Messenger.Unregister method is called. In other words, when you call Register to handle a messsage make sure you call Unregister as well!

So in your view you have to register for the Unloaded event; there you then call Messenger.Unregiser(this); where this is your view.

In ViewModels you have to make sure that the Cleanup method is called to deregister the ViewModel as a message recipient.

Also see:

MVVM Light Listener not releasing / deterministic finalization for registered object? and MVVM Light Messenger executing multiple times.

Laurent is aware of this Problem but - as of now - has no solution.

笑叹一世浮沉 2024-12-03 11:10:30
  1. 在视图之间共享 ViewModel 可能会导致这样的问题。这就是为什么很少这样做的原因。
  2. ViewModel 通常不应该关心导航,因为在理想的世界中它甚至不应该知道它绑定到哪种视图。这包括生成子视图 (ChildWindows)。

我会向你推荐两个改变。第一个是为对话框创建专用视图模型。其次,通过将导航委托给控制器来将导航与视图模型解耦。 MVVM 中的控制器通常是一个单例对象,其全部目的是打开窗口、对话框等。这可以使用事件聚合器模式以相当优雅的方式实现。

  1. Sharing ViewModels between views can lead to problems like this. That's why it's rarely done.
  2. A ViewModel should generally not be concerned with navigation because in an ideal world it shouldn't even know what kind of view it is bound to. This includes spawing child views (ChildWindows).

I would recommend two changes to you. The first one is to create a dedicated viewmodel for your dialog. And second to decouple the navigation from the viewmodel by delegating navigation to a Controller. A controller in MVVM is usually a singleton object who's whole purpose is opening windows, dialogs etc. This can be implemented using the Event Aggregator pattern in a quite elegant fashion.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文