Skip navigation

So after some research, I discovered what it takes to support Input Binding (E.G. key gestures) for the Delegating Command: absolutely nothing. Although you can configure a Routed Command’s Input Bindings using the Command Manager, you can also do it in XAML using UIElement.InputBindings like so:

  <KeyBinding Key="B" Modifiers="Control" Command="ApplicationCommands.Open" />

Here’s the really fun part. You can configure Input Bindings for any ICommand (like a Delegating Command exposed as a property on your View Model (or Acropolis Part)). In all honesty, I’m seeing less and less use for Routed Commands. I for one won’t be using them going forward.

It’s time for us to begin sailing the 4C’s again. I’ve just dusted off Part Two of Code Climber Custom Controls and it’s going to be a doozy just like it’s predecessor. It just needs one more evening/morning writing cycle to complete.



  1. Oh, now that\’s awesome!  Now I\’m back to not caring for RoutedCommands _most_ of the time.  In theory, there will be times you care that your commands be routed through the heirarchy… but when using a ViewModel those times will be rare indeed.
    We\’re still not in Utopia, however.  Though we could roll all of our own commands, it sure seems like it would be useful to not re-implement the standard commands, all of which are of the RoutedCommand variety.   Got any sneaky way to bind these to our ViewModel?  If not, I\’ll still be living with creating some bindings in the ViewModel constructor.

  2. You mean the Application commands like Cut, Copy, Paste, Open and the like? Most controls that use it have built in support for them (like a TextBox supports text editing commands). Open doesn\’t do anything to begin with by default.
    I think the only place for RoutedCommands is when building a custom Control derivative. In this case your viewmodel IS the control. And you register the command bindings directly against the control itself.

  3. Yes, ApplicationCommands, NavigationCommands, etc.  You\’ll want command handlers in your ViewModel for various such commands.  For example, ApplicationCommands.Find is an easy one to imagine wanting.  Or even Open.  These aren\’t (or don\’t have to be) commands tied to a control.  They can be tied directly to your view.
    Even when tied to a control in theory, the functionality is often domain specific and it\’s not a good design to create a custom control just because of this.  The RoutedCommand is fine in every way, except for what it takes to bind it to functionality on our ViewModel.  For most commands, I\’m now very happy to go back to a DelegatingCommand concept, but for the standard commands, I\’m not so willing (and there\’s still the theoretical need for routing for some commands).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: