In a previous chapter of this tutorial, we talked about how to
handle events, e.g. when the user clicks on a button or a menu item. In a
interface, it's typical for a function to be reachable from several
places though, invoked by different user actions.
For instance, if you have a typical interface with a main menu and a
set of toolbars, an action like New or Open might be available in the
menu, on the
toolbar, in a context menu (e.g. when right clicking in the main
application area) and from a keyboard shortcut like Ctrl+N and Ctrl+O.
Each of these actions needs to perform what is typically the exact
same piece of code, so in a WinForms application, you would have to
define an event for
each of them and then call a common function. With the above
example, that would lead to at least three event handlers and some code
to handle the keyboard
shortcut. Not an ideal situation.
With WPF, Microsoft is trying to remedy that with a concept called
commands. It allows you to define actions in one place and then refer to
them from all
your user interface controls like menu items, toolbar buttons and so
on. WPF will also listen for keyboard shortcuts and pass them along to
command, if any, making it the ideal way to offer keyboard shortcuts
in an application.
Commands also solve another hassle when dealing with multiple
entrances to the same function. In a WinForms application, you would be
writing code that could disable user interface elements when the
action was not available. For instance, if your application was able to
use a clipboard
command like Cut, but only when text was selected, you would have to
manually enable and disable the main menu item, the toolbar button and
menu item each time text selection changed.
With WPF commands, this is centralized. With one method you decide
whether or not a given command can be executed, and then WPF toggles all
interface elements on or off automatically. This makes it so much
easier to create a responsive and dynamic application!
Commands don't actually do anything by them self. At the root, they
consist of the ICommand interface, which only defines an event and two
Execute() and CanExecute(). The first one is for performing the
actual action, while the second one is for determining whether the
action is currently
available. To perform the actual action of the command, you need a
link between the command and your code and this is where the
CommandBinding comes into
A CommandBinding is usually defined on a Window or a UserControl,
and holds a references to the Command that it handles, as well as the
handlers for dealing with the Execute() and CanExecute() events of
You can of course implement your own commands, which we'll look into
in one of the next chapters, but to make it easier for you, the WPF
team has defined
over 100 commonly used commands that you can use. They have been
divided into 5 categories, called ApplicationCommands,
EditingCommands and ComponentCommands. Especially
ApplicationCommands contains commands for a lot of very frequently used
actions like New, Open, Save and
Cut, Copy and Paste.
Commands help you to respond to a common action from several
different sources, using a single event handler. It also makes it a lot
easier to enable and
disable user interface elements based on the current availability
and state. This was all theory, but in the next chapters we'll discuss
how commands are
used and how you define your own custom commands.