WPF - jak wymusić na poleceniu ponowną ocenę „CanExecute” za pośrednictwem jego CommandBindings

Mam Menugdzie każdy MenuItemw hierarchii ma swoją Commandwłaściwość ustawioną na RoutedCommandzdefiniowaną przeze mnie. Skojarzony CommandBindingzapewnia wywołanie zwrotne do oceny, CanExecutektóre kontroluje stan włączenia każdego MenuItem.

To prawie działa. Pozycje menu początkowo pojawiają się z prawidłowymi stanami włączenia i wyłączenia. Jednak gdy dane, których CanExecuteużywa moje wywołanie zwrotne, ulegną zmianie, potrzebuję polecenia, aby ponownie zażądać wyniku z mojego wywołania zwrotnego, aby ten nowy stan został odzwierciedlony w interfejsie użytkownika.

Tam nie wydają się być wszelkie metody publiczne na RoutedCommandlub CommandBindingza to.

Zwróć uwagę, że wywołanie zwrotne jest używane ponownie, gdy klikam lub piszę w kontrolce (myślę, że jest wyzwalane przy wprowadzaniu danych, ponieważ najechanie kursorem myszy nie powoduje odświeżenia).

Nie jest to najładniejsze w książce, ale możesz użyć CommandManager do unieważnienia wszystkich poleceń:

CommandManager.InvalidateRequerySuggested();

Zobacz więcej informacji w witrynie MSDN

Dla każdego, kto zetknie się z tym później; Jeśli używasz MVVM i Prism, DelegateCommandimplementacja Prism ICommandzapewnia .RaiseCanExecuteChanged()metodę, aby to zrobić.

Nie mogłem użyć, CommandManager.InvalidateRequerySuggested();ponieważ dostałem hit wydajności.

Użyłem polecenia delegowania MVVM Helpera , które wygląda jak poniżej (trochę go poprawiłem dla naszego wymagania). musisz zadzwonić command.RaiseCanExecuteChanged()z 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);
}

Jeśli wyrzuciłeś swoją własną klasę, która implementuje ICommand, możesz stracić wiele automatycznych aktualizacji statusu, zmuszając cię do polegania na ręcznym odświeżaniu bardziej niż powinno. Może też pęknąć InvalidateRequerySuggested(). Problem polega na tym, że prosta ICommandimplementacja nie łączy nowego polecenia z plikiem CommandManager.

Rozwiązaniem jest użycie:

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

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

W ten sposób subskrybenci przyłączają się do CommandManagerTwojej klasy, a nie do Twojej klasy i mogą odpowiednio uczestniczyć w zmianach statusu poleceń.

Zaimplementowałem rozwiązanie do obsługi zależności właściwości od poleceń, tutaj link https://stackoverflow.com/a/30394333/1716620

dzięki temu otrzymasz takie polecenie:

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

Oto, co zadziałało dla mnie: umieść CanExecute przed poleceniem w kodzie XAML.