prism:Click.Command & Property Binding

Dec 6, 2012 at 2:07 PM
Edited Dec 6, 2012 at 4:45 PM

I have a button that uses the PRISM Click binding:

prism:Click.Command="{Binding ABinding}"

On the same button I have a binding for the IsEnabled property:

IsEnabled="{Binding Path=CheckEnabled}"

The CheckEnabled property[in my ViewModel] does not get called. If I change the PRIMS click binding to a straight Command binding:

Command="{Binding ABinding}"

Then the CheckEnabled property gets called (during binding updates). What I would like to know is why the PRISM click command binding interferes with other bidnings on the control?



Dec 6, 2012 at 7:30 PM

Hi Peter,

Based on my understanding the Click class creates a ButtonBaseClickCommandBehavior when a Click.Command attached property is set (i.e. Click.Command,) used to "map" the Click event of the Button to the Execute method of the Command. This behavior inherits from the CommandBahaviorBase class, which in turn changes the IsEnabled property. This could be the reason why the binding to the CheckEnabled property is being "ignored."

However, take into account that the Click class (and the Click.Command attached property) are obsolete and their usage is discouraged as since Silverlight 4  binding Buttons to Commands is directly supported. Hence, it's recommended to use common Command bindings instead.


Damian Cherubini

Dec 6, 2012 at 9:51 PM

This occurs no matter what property I'm binding. Are you implying that all control properties are circumvented by PRISM.

Note: this is being done in a Desktop application not Silverlight.



Dec 7, 2012 at 5:36 PM

Hi Pryrt,

So far, we could not reproduce the behavior you are describing. Besides the IsEnabled property that is changed by the CommandBehaviorBase class, other properties responded their corresponding bindings correctly. Which properties bindings are failing in your scenario?

Again, take into account that the Click class was created to use Commands in Silverlight 3 and below. As far as I know, this class was not designed to be used in WPF and hence, it should not be used in WPF applications. Our recommendation is to use common Command bindings instead of the Click class.


Damian Cherubini

Dec 7, 2012 at 5:54 PM

If this seems to be a non typical problem then I'll leave it at that. For those who pointed out that Command is the proper use I suggest you re read my question where you will see I am using the Comand object. For those who seem to like to point out that this bhavior was designed explicilty for Silverlight, why do I see it in PRISM for desktop. I'm using the latest version of PRISM and I am using PRISM [project] templates that generate test cases that use this functoinality. So stop brining up this point and direct it to MS to specify that it should be documented as such.


Dec 10, 2012 at 5:05 PM

Hi Peter,

In my case when experiencing this behavior, I found that a possible way to avoid the aforementioned problem could be to set the Mode of the binding in the IsEnabled property to TwoWay (e.g. IsEnabled="{Binding Path=CheckEnabled, Mode=TwoWay}" which by default may be set to OneWay. As based on my understanding, when the CommandBehavior updates the value of this property in the CommandCanExecuteChanged handler, if the mode is set to OneWay the binding will stop working.

So far, when using this behavior I could experience this problem only with the IsEnabled property as my other bindings keep working.

I hope you find this handy,

Agustin Adami