3

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.

  • Are you talking about https://msdn.microsoft.com/en-us/library/system.windows.input.icommand.canexecute(v=vs.110).aspx ? If so, what alternative do you suggest? – MetaFight Sep 16 '15 at 13:09
  • It would help your question if you explained what your better alternative is. – Eric King Sep 16 '15 at 13:11
  • 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! – Sjoerd222888 Sep 16 '15 at 13:50
  • So you're suggesting binding a control to a Command and a bool IsEnabled property? Isn't that more work? – MetaFight Sep 16 '15 at 13:55
  • 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. – Sjoerd222888 Sep 16 '15 at 14:02
  • I'm still a bit confused. What are the actual benefits of using a separate IsEnabled property? – MetaFight Sep 16 '15 at 15:38
  • And if we implement CanExceute I would like to be convinced that this really is a strong feature that people need. Unfortunately I never had a situation where I thought: "That's nice!". I rather always thought: "I can also do this with a property, why does this exist at all?". – Sjoerd222888 Sep 17 '15 at 09:06
  • Your question is backwards. Your question should be "Why implement a second separate property that I have to maintain rather than use the built in functionality of CanExecute?" – 17 of 26 Sep 17 '15 at 14:33
  • I am working on a UI library and wonder whether something like CanExecute should be implemented. I could also have put "If I would build something similar to WPF, what are the big benefits of CanExecute and what would be the drawbacks if I would not provide something like CanExecute" – Sjoerd222888 Sep 18 '15 at 08:08

1 Answers1

6

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.

17 of 26
  • 4,828
  • 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. – Sjoerd222888 Sep 17 '15 at 08:52
  • Your question doesn't make sense. Those things you listed aren't MVVM frameworks. – 17 of 26 Sep 17 '15 at 14:32
  • 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. – Sjoerd222888 Sep 18 '15 at 08:04
  • 1
    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 Feb 23 '16 at 09:54
  • 2
    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) – Peter Duniho Feb 23 '16 at 09:55
  • In theory, different controls that bind to a command may have a custom appearance when command can't be executed, e.g. become invisible instead disabled/greyed out or something more fancy. With ICommand.CanExecute you don't need to think about it – KolA Aug 09 '19 at 20:31