When is icommand.canexecute called

ClickEvent etc. So, you can call that to validate your commands too manually. 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. 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.

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.

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. Updated title: Why ICommand. CanExecute is getting called all the time, instead of working like an event? Here is my VB. C, ModifierKeys. ToLongTimeString ;. So, my example is absurd but I bet you see my point by now: WPF is meant to automatically set the IsEnabled Property on that button to true or false, based on the results of the CanExecute method.

It seems that when events are raised on the Window a mouse button click, etc. But, without further programmatic or user intervention, the button will not automatically change its IsEnabled state once a second. InvalidateRequerySuggested ;. There you have it. This entry is looking a little rough…. Print, any idea why? When the file is open, update the class's signature to make it public and to specify that it will implement ICommand, as follows:.

We can start by adding the Execute method. This accepts an object that can be used to pass a parameter to the command. For the first example we will ignore the parameter and simply display a message box. Add the following method to the InfoCommand class:.

Finally, we need to add the CanExecuteChanged event, This must be present for the correct implementation of the ICommand interface, even though we will not raise the event manually for this command. Add the event, as follows:.

The InfoCommand class now represents a reusable command that contains all of its own functionality and knowledge of when it can be executed. Once you have created a command that you wish to execute in response to user events, you need to provide some way for the user to call it. We will expose the command through the main window's data context as a property, then link it to a button using a binding expression.