WPF - Comment forcer une commande à réévaluer 'CanExecute' via ses CommandBindings

J'ai un Menuoù chacun MenuItemdans la hiérarchie a sa Commandpropriété définie sur un RoutedCommandque j'ai défini. L'associé CommandBindingfournit un rappel pour l'évaluation de CanExecutequi contrôle l'état activé de chacun MenuItem.

Cela fonctionne presque . Les éléments de menu présentent initialement les états activés et désactivés corrects. Cependant, lorsque les données que mon CanExecuterappel utilise changent, j'ai besoin de la commande pour demander à nouveau un résultat de mon rappel afin que ce nouvel état soit reflété dans l'interface utilisateur.

Il ne semble pas y avoir de méthodes publiques sur RoutedCommandou CommandBindingpour cela.

Notez que le rappel est utilisé à nouveau lorsque je clique ou tape dans le contrôle (je suppose qu'il est déclenché en entrée car le survol de la souris ne provoque pas l'actualisation).

Ce n'est pas le plus joli du livre, mais vous pouvez utiliser le CommandManager pour invalider toutes les liaisons de commandes:

CommandManager.InvalidateRequerySuggested();

Voir plus d'informations sur MSDN

Pour tous ceux qui rencontrent cela plus tard; Si vous utilisez MVVM et Prism, l' DelegateCommandimplémentation de Prism ICommandfournit une .RaiseCanExecuteChanged()méthode pour ce faire.

Je ne pouvais pas utiliser CommandManager.InvalidateRequerySuggested();parce que mes performances étaient affectées.

J'ai utilisé la commande de délégation de MVVM Helper , qui ressemble à ci-dessous (je l'ai un peu modifiée pour notre demande). vous devez appeler command.RaiseCanExecuteChanged()depuis VM

public event EventHandler CanExecuteChanged
{
    add
    {
        _internalCanExecuteChanged += value;
        CommandManager.RequerySuggested += value;
    }
    remove
    {
        _internalCanExecuteChanged -= value;
        CommandManager.RequerySuggested -= value;
    }
}

/// <summary>
/// This method can be used to raise the CanExecuteChanged handler.
/// This will force WPF to re-query the status of this command directly.
/// </summary>
public void RaiseCanExecuteChanged()
{
    if (canExecute != null)
        OnCanExecuteChanged();
}

/// <summary>
/// This method is used to walk the delegate chain and well WPF that
/// our command execution status has changed.
/// </summary>
protected virtual void OnCanExecuteChanged()
{
    EventHandler eCanExecuteChanged = _internalCanExecuteChanged;
    if (eCanExecuteChanged != null)
        eCanExecuteChanged(this, EventArgs.Empty);
}

Si vous avez lancé votre propre classe qui implémente, ICommandvous pouvez perdre une grande partie des mises à jour automatiques de statut, vous obligeant à compter sur une actualisation manuelle plus que nécessaire. Cela peut aussi casser InvalidateRequerySuggested(). Le problème est qu'une ICommandimplémentation simple ne parvient pas à lier la nouvelle commande au CommandManager.

La solution consiste à utiliser ce qui suit:

    public event EventHandler CanExecuteChanged
    {
        add { CommandManager.RequerySuggested += value; }
        remove { CommandManager.RequerySuggested -= value; }
    }

    public void RaiseCanExecuteChanged()
    {
        CommandManager.InvalidateRequerySuggested();
    }

De cette façon, les abonnés s'attachent à CommandManagerplutôt qu'à votre classe et peuvent participer correctement aux changements d'état des commandes.

J'ai implémenté une solution pour gérer la dépendance des propriétés sur les commandes, ici le lien https://stackoverflow.com/a/30394333/1716620

grâce à cela, vous finirez par avoir une commande comme celle-ci:

this.SaveCommand = new MyDelegateCommand<MyViewModel>(this,
    //execute
    () => {
      Console.Write("EXECUTED");
    },
    //can execute
    () => {
      Console.Write("Checking Validity");
       return PropertyX!=null && PropertyY!=null && PropertyY.Length < 5;
    },
    //properties to watch
    (p) => new { p.PropertyX, p.PropertyY }
 );

C'est ce qui a fonctionné pour moi: mettez le CanExecute avant la commande dans le XAML.