WPF - Como forçar um comando para reavaliar 'CanExecute' através de suas CommandBindings

Eu tenho um em Menuque cada MenuItemhierarquia tem sua Commandpropriedade definida como RoutedCommanddefinida. O associado CommandBindingfornece um retorno de chamada para a avaliação da CanExecutequal controla o estado ativado de cada um MenuItem.

Isso quase funciona. Os itens de menu aparecem inicialmente com os estados ativados e desativados corretos. No entanto, quando os dados que meu CanExecuteretorno de chamada usa são alterados, preciso do comando para solicitar novamente um resultado do retorno de chamada para que esse novo estado seja refletido na interface do usuário.

Não parece haver quaisquer métodos públicas sobre RoutedCommandou CommandBindingpara esta.

Observe que o retorno de chamada é usado novamente quando clico ou digito no controle (acho que foi acionado na entrada porque o mouse não causa a atualização).

Não é a mais bonita do livro, mas você pode usar o CommandManager para invalidar todas as ligações de comando:

CommandManager.InvalidateRequerySuggested();

Veja mais informações no MSDN

Para quem se deparar com isso mais tarde; Se você estiver usando MVVM e Prism, a DelegateCommandimplementação de Prism ICommandfornece um .RaiseCanExecuteChanged()método para fazer isso.

Eu não poderia usar CommandManager.InvalidateRequerySuggested();porque estava sendo atingido pelo desempenho.

Eu usei o comando Delegating do MVVM Helper , que se parece com abaixo (eu ajustei um pouco para o nosso req). você tem que ligar command.RaiseCanExecuteChanged()da 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 você tiver implementado sua própria classe que implementa, ICommandpoderá perder muitas atualizações automáticas de status, forçando-o a confiar na atualização manual mais do que seria necessário. Também pode quebrar InvalidateRequerySuggested(). O problema é que uma ICommandimplementação simples falha ao vincular o novo comando ao CommandManager.

A solução é usar o seguinte:

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

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

Dessa forma, os assinantes se conectam à CommandManagerclasse e não à sua classe e podem participar adequadamente das alterações no status do comando.

Eu implementei uma solução para lidar com a dependência de propriedade nos comandos, aqui o link https://stackoverflow.com/a/30394333/1716620

graças a isso, você terá um comando como este:

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

Isto é o que funcionou para mim: Coloque o CanExecute antes do comando no XAML.