M-V-VM: Alternative approach to implement ShortCut Keys with DelegateCommands

May 16, 2009 at 6:43 PM

It’s not that easy to bind a ShortCut Key to a DelegateCommand because of a annoying WPF issue.
I have seen that you solved this problem by introducing the CommandReference class. The following code extract is from the MainView.xaml of the ContactBook solution (v 0.1):
    <!-- Allows a KeyBinding to be associated with a command defined in the View Model  -->
    <c:CommandReference x:Key="ExitCommandReference" Command="{Binding ExitCommand}" />
    <c:CommandReference x:Key="ClearContactBookCommandReference" Command="{Binding ClearContactBookCommand}" />

    <KeyBinding Key="X" Modifiers="Control" Command="{StaticResource ExitCommandReference}" />
    <KeyBinding Key="B" Modifiers="Control" Command="{StaticResource ClearContactBookCommandReference}" />

That’s a nice workaround. However, maybe you are interested to see an alternative solution to overcome this WPF issue:

Best Practices: How to implement ShortCut Keys with DelegateCommands


May 18, 2009 at 10:34 PM

Hi Jbe-

You're correct in that the CommandReference is to work around the issue with the key binding. In putting the CommandReference in the template & toolkit, we primarily wanted to provide a solution (rather than 'the' solution) that would be inline with the concept of M-V-VM, and if possible avoid having to write code-behind.

Having said that, I'm sure many will be happy to learn that we are fixing this in WPF 4.0, where you will be able to bind to an ICommand directly from the KeyBinding in XAML. Thanks!

May 20, 2009 at 5:16 PM

That sounds great, Patrick.

Any ideas on how the binding syntax is going to look for that? 

How are you going to be able to specify/distinguish between collisions?  Will there be a way to qualify the command binding?

From a side note, I would really be interested not only in the template side of things, but in a tricked-out class designer to facilitate the commanding process.  Just shooting from the hip, here, but if you used partial classes and a separate file it would keep the code clean and allow for an interesting design story for the drudgework of building up commands.



May 21, 2009 at 3:10 AM
Edited May 21, 2009 at 3:10 AM

Hi James-

The syntax will actually be closer to what you are normally used to in WPF. So, instead of having KeyBinding's Command property be limited to static references, it will allow for data binding directly to the view model, similar to how you could do so with Button's Command property. In markup, something like <KeyBinding Command={Binding ViewModelCommand} /> instead of having to do <KeyBinding Command={StaticResource ViewModelCommandReference} /> and having the ViewModelCommandReference call the ViewModelCommand. Pretty simple, but saves from having to work around the limitation.

With respect to resolving which binding to use, the same rules that normally apply with a control's data context will now apply with the key binding. In other words, if you define a key binding locally that's different from a "root" key binding, the local one will take precedent if that element has focus.

There is work underway in VS 2010 to improve the design experience of WPF and data binding, which hopefully will help address some of the pain. If you have some time, I would suggest giving the recently released Beta1 a try, and keeping an eye out for upcoming features. Link: http://www.microsoft.com/visualstudio/en-us/products/2010/default.mspx

Thanks again for your support, we appreciate it!