Please Add CanDeactivate function to Screen

Topics: UI Architecture
May 19, 2011 at 9:36 AM

we need to be able to prevent deactivating Screen in Conductor.Collection.OneActive scenario (like CanClose).

I there any architectural reason to not include this in Screen class ?

May 19, 2011 at 10:53 AM
Edited May 19, 2011 at 12:47 PM

I don't know if there is a reason but i just want to describe my solution, which is in my mind, because I have the same issue i want to realize soon.

I think it's not a big thing to implement. Just make a new interface like IDeactivationGuard with a method CanDeactivate and
let all your conducted screens implement it. At the point you handle the activation, call this method:


If somebody has a nicer solution, let us know, since I am looking always for the perfect way.

May 22, 2011 at 11:34 AM
Edited May 22, 2011 at 11:41 AM

I have implemented CanDeactivate. If it is helpful for someone, here is my code:

Step 1: Add this method to IDeactivate:

/// <summary>
/// Called to check whether or not this instance can be deactivated.
/// </summary>
/// <value><c>true</c> if can be deactivated; otherwise, <c>false</c>.</value>
bool CanDeactivate();

Step 2: Add this implementation to Screen, which returns true by default:
/// <summary>
///   Called before deactivating.
/// </summary>
public virtual bool CanDeactivate() { return true; }

Step 3: To the method ActivateItem of the nested class OneActive add the following lines of code just before the method caller ChangeActiveItem(item, false)
var activeItem = ActiveItem as IDeactivate;
if (activeItem != null && !activeItem.CanDeactivate())

Step 4: Now you can override CanDeactivate() in your screens.


Note: It’s tested with RTW release.
Mar 22, 2012 at 1:01 AM
Edited Mar 22, 2012 at 1:01 AM

Has anything like this been implemented in the main CM stream?  I downloaded the latest source and don't see it, at least not in this form.

If not yet implemented, is it because it's not deemed necessary, or simply for lack of someone doing it?

Mar 30, 2012 at 3:50 PM

I would like to ask the same Question

In the above posting it seems that Tongo has written IDeactivate and that bevor CM went RTW he also implemented CanDeactivate.
But in the current code I can't find it.

Would it be possible for you to implement this "again" or were there reasons why it hasn't gone live?
Of course I could implement byself local and compile, but then I would be imcompatible to CM.

Thanks a lot in advance of a reply.


Sep 28, 2013 at 8:42 AM
I'm also facing the need to guard deactivation.

Has there been any troubles with this implementation so far? I'm using 1.5.2.
Oct 30, 2013 at 7:37 PM
At the moment we are in development of 2.0 version where API changes can be made.
I would suggest that instead of modifying IDeactivate you create a new interface IGuardDeactivate like it the existing IGuardClose interface.
Jan 11, 2014 at 5:20 PM
Did anyone experience problems while using a tabcontrol and this tactic? I can't get it to work correctly. The child screen stays the same (correct), but the tab control itself shows a different tab selected, and I can't seem to make that selection (the visible part of it) to bind to something so I can manually set that. Any thoughts?
Aug 16, 2014 at 4:07 PM
I've dealt with the tab control issue before. It is solvable, but it requires some hacking. I've written up a WPF attached behavior that can handle this. It was originally written with Prism in mind, but it is really framework agnostic.

You can see the full source code at my Github

Focus on:
static void view_CurrentChanging(object sender, CurrentChangingEventArgs e)
    var items = (ItemCollection)sender;

    if (e.IsCancelable && items.CurrentItem != null)
        var currentView = items.CurrentItem as FrameworkElement;
        if (currentView == null) return;
        var selector = FindVisualParent<Selector>(currentView);
        if (selector == null) return;

        var vetoingSource = currentView as IConfirmDeactivate ?? currentView.DataContext as IConfirmDeactivate;
        if (vetoingSource != null && !vetoingSource.ConfirmDeactivation())
            e.Cancel = true;

        selector.Dispatcher.BeginInvoke(new Action(items.Refresh));
It checks the view and view model of the current tab for an implementation of IConfirmDeactivation. If found it calls ConfirmDeactivation(). Based on the result you can cancel or continue the tab change