The WPF Files: The Final Piece of the Puzzle (Premium)

To complete my quick-and-dirty port of .NETpad to WPF and .NET Core, I had to overcome one final obstacle: Keyboard shortcuts.

There are many such obstacles in WPF. For example, I previously highlighted font support as one of the areas in which Microsoft really dropped the ball in moving from Windows Forms to Windows Presentation Foundation (WPF): Developers who wish to provide font customization access to their users will either need to roll their own Font dialog or jump through some hoops to use the old WinForms version and then deal with all the incompatibilities between its underlying Font class/object and the new font-related classes and objects provided by WPF.

That’s a mess, but it’s only one example. And in looking at my quick-and-dirty port of .NETpad from C#/WinForms/.NET Framework to C#/WPF/.NET Core, there was one final hurdle to overcome and it, too, is another example of Microsoft dropping the ball. I’m referring, of course, to keyboard shortcuts.

Consider the WinForms versions of .NETpad. If the user wants to access the Open command, which provides a system Open file dialog so that they can open an existing file, they can either navigate to File > Open or they can tap the CTRL + O keyboard shortcut. Linking that keyboard shortcut to the Open menu item’s Click event handler is simple: You just select the Open menu in the designer and then locate the ShortcutKeys property in the Properties pane. Visual Studio provides a nice interface for configuring exactly the keyboard shortcut you want.

When you configure this property, the keyboard shortcut also appears in the Open menu to the right of the Open text. And you could also optionally use the ShortcutKeyDisplayString property to customize that text if needed. We did this in the VB version of .NETpad for the Zoom In and Zoom Out menu items, because the default display strings (Ctrl+OemPlus and Ctrl+OemMinus) were not ideal. But whatever: It was simple.

WPF uses a completely different and far more complex system for assigning keyboard shortcuts to menu items and other commands. There are all kinds of reasons and rationale for this new system, which I’m not going to describe in any detail. My point is only that they took something simple and just over-designed it. It’s a hot mess that involves binding keyboard shortcuts to built-in commands or custom commands.

Built-in commands---common application actions like New, Open, Save, and so on---are easiest, but they require you to make changes to the applicable window’s XAML and C# code. On the XAML end, you can add a <Window.CommandBindings> section in which you declare these bindings. For example, if you just want to add a CTRL + O keyboard shortcut for the Open command, it could look like so.
<Window.CommandBindings>
    <CommandBinding Command="Open" CanExecute="OpenCommand_CanExecute" Executed="OpenCommand_Executed" />
</Window.CommandBindings>
Then, you need to...

Gain unlimited access to Premium articles.

With technology shaping our everyday lives, how could we not dig deeper?

Thurrott Premium delivers an honest and thorough perspective about the technologies we use and rely on everyday. Discover deeper content as a Premium member.

Tagged with

Share post

Please check our Community Guidelines before commenting

Windows Intelligence In Your Inbox

Sign up for our new free newsletter to get three time-saving tips each Friday

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

Thurrott © 2024 Thurrott LLC