Little documentation on CanExecute support, can I get some clarification?

Topics: Actions & Coroutines, Conventions
Mar 7, 2012 at 7:38 PM

Fairly new to using binding-by-convention.  I discovered via trial-and-error that you can essentially create a CanExecute like such:

<Button x:Name="Property"/>

public void Property(){ }

public bool CanProperty { get { return true; } }


I did not find this in the documentation, so I was pleasantly surprised to see this.  However I noticed that CanProperty is only evaluated once, and then done.  I remedied this by raising the INPC event on CanProperty when the right property was updated, but I find this to be cumbersome and unreliable.  It feels like it's the wrong way to do it.  For instance, what if the property I want to evaluate within the "canExecute" is not in the class scope or is a framework property I have not touched otherwise?  It would not be supported in this case unless I am mistaken.


Is there an official way to handle CanExecutes?

Mar 7, 2012 at 7:50 PM

It is indeed the correct approach: you are responsible to notify the Action sub-system of a guard property change.

I understand it is cumbersome, but if you design your availability logic well, it is not so bad. Regarding your question, the guard and the action should mainly live in the same class... otherwise,  the class providing the action should allow the guard to be publicly re-evaluated.

Mar 7, 2012 at 7:58 PM
Edited Mar 7, 2012 at 7:59 PM

Fair assessment.  Of course I could still implement command bindings but I'd rather not throw out Caliburn's Action system just over a slightly cumbersome design.  Thanks for the assistance.