Updated title: Why ICommand.CanExecute is getting called all the time, instead of working like an event?

Question

I am adopting MVVM pattern in WPF and have learned the use of Command. But in my implementation, the delegate I assigned to implement CanExecute is alw

Answer 1

May be for unknown reason the UI could be getting updated (Measure, Arrange, and then Render calls). And if you have a breakpoint set on can execute method it'll be re-occurring. In other words you can't get pass this break point, each time you would do F5, the break point will it again.

To investigate you should put the logging/output statements in your can execute method and how many times and when it is getting called.

Answer 2

In your CanExecuteDelegate you have hook to CommandManager.RequerySuggested.

So, whenever CommandManager.RequerySuggested is raised your CanExecuteDelegate will be called.

CommandManager.RequerySuggested event is raised whenever changes to the command source are detected by the command manager which ranges from Keyboard.KeyUpEvent, Mouse.ClickEvent etc.

Also, CommandManager has a static method - InvalidateRequerySuggested which forces the CommandManager to raise the RequerySuggestedEvent. So, you can call that to validate your commands too manually.

If you want to take the control in hand for raising CanExecute, you can use the Delegate Command provided by PRISM. CanExecute delegate will get called only when you explicitly call RaiseCanExecuteChanged() method exposed by Delegate Command.

Incorporating comments to answer

Breakpoint is hitting every time on turning to VS since CommandManager RequerySuggested event gets called on lost focus of window and on activation property changed of window. That's why you notice that breakpoint is hitting every now and then when you move to VS since focus moves from WPF window to Visual Studio.

Answer 3

When you set up your command, there's no reliable way for the runtime to know what data your CanExecute will rely on in order to make its decision. So, when you have commands that are bound into your UI and are registered in the CommandManager, the behaviour is that the CanExecute for all commands is re-evaluated whenever the state of your application changes. The way WPF knows about this is when a bound property is updated, or when a UI event occurs.

Typically you'll see CanExecute called whenever bindings update or when certain control events occur (for example, when a textbox's text is highlighted, the CanExecute of the inbuilt Cut and Copy commands will change, and so the highlight event triggers a re-evaluation that I would imagine is bound to the MouseUp event).