RelayCommand RaiseCanExecuteChanged() 失败

Question

I am using a couple of Buttons bound to RelayCommands initialized with CanExecute delegates.

RelayCommand DeleteCommand;
bool CanDelete()
{
    return BoolProp1 && BoolProp2;
}

...

DeleteCommand = new RelayCommand(Delete, CanDelete);

BoolProp1 and BoolProp2 are regular properties with setters correctly raising PropertyChanged , but as we all know, this is not enough to make SL reevaluate CanExecute on commands. That's why i also call Delete.RaiseCanExecuteChanged() in both setters.

All this works fine (buttons are disabled and enabled properly) up to some point, where is all stops. At that point, calling Delete.RaiseCanExecuteChanged() no longer fires my breakpoints in CanDelete() and buttons forever stay the way they were.

I spend 2 hours trying to isolate the exact cause with no effect. I suspect multiple RaiseCanExecuteChanged() calls during single "binding iteration" somehow break the mechanism.

Any hints? I'm already considering using an additional IsExecutable field refreshed through INotifyPropertyChanged ...

UPDATE

RelayCommand is actually GalaSoft.MvvmLight.Command.RelayCommand from MVVM Light Toolkit . ILSpy shows a pretty trivial implementation of ICommand:

public bool CanExecute(object parameter)
{
    return this._canExecute == null || this._canExecute.Invoke();
}

public void RaiseCanExecuteChanged()
{
    EventHandler canExecuteChanged = this.CanExecuteChanged;
    if (canExecuteChanged != null)
    {
         canExecuteChanged.Invoke(this, EventArgs.Empty);
    }
}

with _canExecute being a Func<bool> set once to the value passed to constructor.

I am still working to minimally reproduce the issue.

UPDATE

See my answer.

Answer 1

PEBKAC. My framework in certain cases ran the code

DeleteCommand = new RelayCommand(Delete, CanDelete);

more then once, overwriting commands that were actually bound to view with new instances.

If somebody has this problem - make sure you're calling RelayCommand.RaiseCanExecuteChanged() on the same instance that the view is bound to.

Answer 2

For anyone else who faced the same issue and the accepted answer didn't help me (and for my own record, as I spent a few hours today with it).

If you're using MVVM Light in a VSTO add-in, make sure that the Office application gets a chance to process its own messages to get this to work. For example, in my case I had my Ribbon buttons listening to CanExecuteChanged of underlying VM's command objects, which would not fire no matter what I did. After spending a few hours, I realized that I had to let Office application take a breath and process incoming message to allow CanExecuteChanged to be caught by the add-in. What I then did was to hand over my RaiseCanExecuteChanged function to DispatcherHelper to let it fire asynchronously. It was only then that my Ribbon buttons started reacting to CanExecuteChanged events. Something like this:

DispatcherHelper.CheckBeginInvokeOnUI(() =>
{
  doc.Activate();
  ResetVariablesCommand.RaiseCanExecuteChanged();
});