Generic Command Binding with WPF and Prism

I’ve been working with WPF a lot lately for a client project and I’ve learned some pretty cool tricks along the way.  I am planning to do a bunch of posts describing many of these tricks in the near future.  The first cool trick I will be talking about is how to make a control that switches between editable mode and read-only mode using only XAML, kind of.

I say ‘kind of’ because we will have some code to make it happen, but not in the code-behind.  Rather than use a code-behind, we will be leveraging the Model-View-ViewModel (MVVM) design pattern to keep our code separate and testable.

Let’s dive right into the code by taking a look at the view model.  Since we will be leveraging WPF’s awesome data binding, we need to prepare the view model to allow WPF to keep track of property changes.  To do this, our view model will implement INotifyPropertyChanged.  Doing so will allow the WPF binding engine to listen for changes and update the view accordingly.

You’ll notice that I added a method called NotifyPropertyChanged.  This is just to simplify the process of raising the event from the property setters.

Next up we will set up the properties that the view will be binding to.  Our example is very simple, so there will only be two properties in the view model: IsReadOnly and Name.

Notice that both of the setters make a call to NotifyPropertyChanged, giving the name of the respective property.  That is what will signal the binding engine to update anything that is bound to one of those two properties.

That’s it for the view model.  We’re keeping things simple.  Let’s move on to the view itself.  First things first, we need to set up the view model as the DataContext.

Next up we are going to set up some the style for the ContentControl.

Now, this is where the magic happens.  You’ll see that we have a style here with two DataTriggers.  Both of the DataTriggers bind to the IsReadOnly property of our view model.  One of the DataTriggers handles when IsReadOnly is True and the other handles when IsReadOnly is False.

If IsReadOnly is True, we set the Template to a Grid with a static Label.  The Label is bound to the Name property.

If IsReadOnly is False, we set the Template to a Grid with a TextBox.  The TextBox also binds to the Name property and sets UpdateSourceTrigger=PropertyChanged.  The reason for this is that the binding would normally wait to trigger an update to the property until it loses focus.  Setting UpdateSourceTrigger=PropertyChanged will trigger the update with every key press.

The only missing piece to this puzzle is to place the actual ContentControl.

To use the style we created above, we simply need to bind the Style of the ContentControl to the Style with the Key Name.  You’ll also notice that I have placed a CheckBox in there as well, giving a way to test that the whole operation works.

So, that pretty much wraps it up.  We now have a control that completely changes it’s look based on only a boolean value.  Although this example is quite simple, this approach can be applied to more complex situations.  You can take the solution at the end of the post and poke around a little.

Hopefully this has been helpful!  Have fun with it!

2 thoughts on “Generic Command Binding with WPF and Prism”

  1. Hi Brent,

    Tank’s for this excellent article. May be a best pattern for generic command binding but I have one question.
    How I can pass a command parameter in WPW for example MouseWheelEventArgs on MouseWheel event to the commander.

    commands:Commander.Command=”{Binding MoveLeftCommand}”
    commands:Commander.CommandParamter= ?????????

    Best regards


  2. @Radoslav

    CommandParameter is a DependencyProperty, which means that it is bindable using the {binding …} syntax. However, if you are trying to get the MouseWheelEventArgs that typically get passed into the event handler, I think you are out of luck using this approach.

    If you happen to be using the business object framework, CSLA, you will have better luck because CSLA 3.8 has some new features that do the same thing that the above approach does, but makes it even more user friendly. In addition, you will find that the optional event args that CSLA passes in will have your MouseWheelEventArgs rolled in.

    Hope this helps!

Comments are closed.