This one is a little bit more tricky then the CommandProxy I’ve written before, because the CommandProxy dose not work here.
First you can simply not apply InputBindings from Styles because the property has not setter. You are only able to add bindings to the collection, but there is no way to do this in styles. Second you can not place there resource for the CommandProxy inside of the style.
To make that work you need an property which you can set in the style. And this is my solution. Create an attached dependency property which set the InputBinding for you.
As example i use the LeftDoubleClick MouseGesture.
public static class MouseCommands
private static void LeftDoubleClickChanged(DependencyObject sender, DependencyPropertyChangedEventArgs args)
var control = (Control)sender;
if(args.NewValue != null && args.NewValue is ICommand)
var newBinding = new MouseBinding(args.NewValue as ICommand, new MouseGesture(MouseAction.LeftDoubleClick));
var oldBinding = control.InputBindings.Cast<InputBinding>().First(b => b.Command.Equals(args.OldValue));
public static readonly DependencyProperty LeftDoubleClickProperty =
public static void SetLeftDoubleClick(DependencyObject obj, ICommand value)
public static ICommand GetLeftDoubleClick(DependencyObject obj)
And then you can apply this over a style. In my example here for an ListBoxItem in its ListBoxContainerStyle.
When you start using the ViewModel pattern in WPF, some day you stumble upon that it is not possible to databind an command to an MouseBinding or KeyBinding.
So why this is not possible?
The WPF DataBinding’s are heavily based on DependencyPropertys which are only work on objects which inherit from DependencyObject. But the Command property on Mouse- and KeyBinding isnt an DependencyProperty. So DataBinding will not work on them.
The next problem is that the InputBinding class is only derived from DependencyObject and so it has no inheritance context which allow to get access to DataContext and ElementName.
May it is a performance consideration, may it is mistake, finally i dont know why they make this decision.
As the name suggests, all this class dose is to expose a ICommand interface and redirect its methods to the databound command. The inheritance context problem is resolve by inherting from Freezable. You can read more about why Freezable helps here, in Dr. WPFs Blog here.
Did you ever noticed that there a way in expression blend to directly edit a second content property of a element which is not the default content and without using a resource? Yep, look at the “<> Header”, there could be placed the second content.
WPF per default provides some of this controls. In example MenuItem,HeaderedContentControl,BulletDecorator … So ive started to find out how to create such a property by myself. After some time of searching ive saw only the way to use Reflector to figure out why Expression Blend exposes this properts.
And the answer is not nice. The hardcoded this behavior into Blend for every control which exposes such a property.
I couldnt belive it, there must be a common way to do it, so ive decided to write a feature request to Microsoft Connect for exposing a common way to expose such a property from my custom code (my first report to Microsoft Connect).
And here is it: https://connect.microsoft.com/Expression/feedback/ViewFeedback.aspx?FeedbackID=411558
My expectation was that this would be a long time open, but it was not. It was closed at the same day ive reported it and with the information i want to hear
Thanks for the feedback- in the next version of Expression Blend we will be adding a new attribute which will allow additional content properties on controls’ Look for ‘AlternateContentPropertyAttribute’ in the next version of the extensibility APIs.
I am looking forward to the next Blend release.
Update: Here is a link how this feature look like in the next Blend version.