WPF - Come forzare un comando a rivalutare 'CanExecute' tramite i suoi CommandBindings

Ho un Menudove ognuno MenuItemnella gerarchia ha la sua Commandproprietà impostata su un RoutedCommandche ho definito. Il associato CommandBindingfornisce un callback per la valutazione di CanExecutequale controlla lo stato abilitato di ciascuno MenuItem.

Questo funziona quasi . Le voci di menu inizialmente presentano gli stati abilitati e disabilitati corretti. Tuttavia, quando i dati utilizzati dal mio CanExecutecallback cambiano, ho bisogno del comando per richiedere nuovamente un risultato dal mio callback affinché questo nuovo stato si rifletta nell'interfaccia utente.

Non sembra esserci alcun metodo pubblico su RoutedCommando CommandBindingper questo.

Si noti che il callback viene utilizzato di nuovo quando si fa clic o si digita il controllo (suppongo che sia attivato sull'input perché il passaggio del mouse non provoca l'aggiornamento).

Non il più grazioso del libro, ma puoi usare il CommandManager per invalidare tutti i comandi:

CommandManager.InvalidateRequerySuggested();

Vedi maggiori informazioni su MSDN

Per chiunque lo incontri più tardi; Se ti capita di usare MVVM e Prism, l' DelegateCommandimplementazione di Prism di ICommandfornisce a.RaiseCanExecuteChanged() metodo per farlo.

Non ho potuto usare CommandManager.InvalidateRequerySuggested(); perché stavo ottenendo un grande successo.

Ho usato il comando di delega MVVM Helper , che appare come di seguito (l'ho modificato un po 'per il nostro req). devi chiamare command.RaiseCanExecuteChanged()dalla 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);
}

Se hai implementato la tua classe che implementa ICommand, puoi perdere molti degli aggiornamenti automatici dello stato costringendoti a fare affidamento sull'aggiornamento manuale più del necessario. Può anche rompersi InvalidateRequerySuggested(). Il problema è che una semplice ICommandimplementazione non riesce a collegare il nuovo comando aCommandManager .

La soluzione è utilizzare quanto segue:

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

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

In questo modo gli abbonati si collegano CommandManagerpiuttosto che alla tua classe e possono partecipare correttamente alle modifiche dello stato del comando.

Ho implementato una soluzione per gestire la dipendenza dalle proprietà dai comandi, qui il link https://stackoverflow.com/a/30394333/1716620

grazie a ciò finirai per avere un comando come questo:

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 }
 );

Questo è ciò che ha funzionato per me: metti CanExecute prima del comando in XAML.