Usefulness of the Command CanExecute as it exists in WPF

Question

I want to question the usefulness of the CanExecute functionality in WPF (defined in the ICommand interface). As I think that you can achieve the same functionality thing without this feature I ask myself why it is there in the first place.

My question is: If I build a new UI framework like WPF from scratch and I have to decide whether to include something similar to CanExecute, what are the arguments against or in favor of such a feature?

---

At the moment my opinion that if you favor simplicity this feature should be excluded as similar functionality can easily be achieve with an additional view-model property representing whether the command can currently be executed. Maybe my assumption is wrong and CanExecute really is an elegant feature, in this case I would ask you to provide convincing arguments.

• MetaFight: Are you talking about msdn.microsoft.com/en-us/library/… ? If so, what alternative do you suggest?
• Eric King: It would help your question if you explained what your better alternative is.
• Sjoerd222888: The alternative, as described in the question, is a boolean property on the view-model that does represent if the command can be executed. It could be that I do not understand the true value of CanExecute because I currently think I could live very good without it. I think CanExecute is not really needed. Not having it seems the better alternative because that reduces complexity. @MetaFight: yes!
• MetaFight: So you're suggesting binding a control to a Command and a bool IsEnabled property? Isn't that more work?
• Sjoerd222888: I agree it's a little bit more work, but not really a big deal I think. Essentially the implementation is quite similar. So an argument in favor of CanExecute is that you write less code.

Answer 1

CanExecute has a couple of benefits over adding an IsEnabled property:

• Each UI element that is bound to the command only needs 1 binding instead of 2 (this is both less work and, more importantly, less error prone). It is common to have multiple views for a viewmodel or to have multiple UI elements bound to a single command (context menus are a prime example).
• The CommandManager will automatically call CanExecute to update the state of the button which means you don't need to manually track and fire property change events for IsEnabled. This is particularly convenient if your CanExecute depends on multiple conditions.

I would argue that adding a second property to separately track CanExecute increases complexity.

Also consider that other programmers who are familiar with MVVM will expect the Command to provide a CanExecute function and will be surprised when it does not.

• Sjoerd222888: What MVVM frameworks other than WPF, Windows Store Apps and Windows Phone Apps do provide CanExecute? I thought it where only the M$ MVVM libs that have CanExecute.
• 17 of 26: Your question doesn't make sense. Those things you listed aren't MVVM frameworks.
• Sjoerd222888: Ok, I meant UI libraries that provide CanExecute. I used the term MVVM because WPF and the other libraries form theris design are very suited for MVVM and most applications get developed in MVVM. It is the prefered pattern for WPF but of course you can also do MVC.
• Peter Duniho: I am curious about the question as well. For me, the main question is why have CanExecute() as a method, instead of an observable property? 2 bindings aren't required...the property could just be in ICommand and so assumed just as CanExecute() is now. Likewise, a property can still be associated with an event (e.g. CanExecuteChanged, PropertyChanged, etc.) to support notification. And CommandManager could just as easily call a property getter as call the CanExecute() method.
• Peter Duniho: The only advantage that seems real to me is that the method can accept a parameter, but that's never mentioned in the answer above (nor have I found anyone bring that up as a key argument in favor of the CanExecute() method)