Global Hotkey/Shortcut Manager in WPF Prism (MVVM)

Question

How can I create a global hotkey binding in a wpf prism application, to which modules can add hotkeys dynamically ?

I tried the following:

Binding the Window.InputCommands to a ObservableCollection of my Hotkey class (using a
common service as model) --> InputCommands does not contain a accessable setter

Working with the PreviewKeyDownEvent (EventToCommand) --> There are no solid ways to determine if Ctrl or Alt is pressed (out of doing it by myself in the ViewModel). I don't like this approach.

Is there any easy way to Add key bindings dynamically?

Answer 1

I don't know how to easily dynamically add/remove in pure MVVM. I'd want to access InputBindings from code-behind, as you duly noted the lack of a setter. However, you may be inclined to break the design for this case only by looking into these two: InputBindings and KeyGesture. So consider creating a custom control for your shell.

    public ObservableCollection<HotkeyModel> Hotkeys { get; private set; }
    public class HotkeyWindow : Window
    {
        HotKeys = new ObservableCollection<HotkeyModel>();
        HotKeys.CollectionChanged += new NotifyCollectionChangedEventHandler(HotkeysChanged);
    }
    void HotkeysChanged(object sender, NotifyCollectionChangedEventArgs e)
    {
        if(e.Action == NotifyCollectionChangedAction.Add)
        {
            foreach(HotkeyModel hk in e.NewItems)
                this.InputBindings.Add(new InputBinding(hk.Command), new KeyGesture(hk.Key, hk.Modifier));
        }
        else if(e. Action == NotifyCollectionChangedAction.Remove)
            ...
    }

Don't set the InputBindings, instead you'd add and remove. Keep that ObservableCollection of Hotkeys and listen for the CollectionChanged Event. As they are added and removed, you add and remove from the InputBindings. As you create a KeyGesture, you can set Keyboard.Modifiers.

So you could take this concept and extrapolate into a true and thorough MVVM design with attached/dependency properties and attached behaviors etc, to stick to the View and ViewModel separation that my above example ignores for now.