More on Commands, Input and the WPF - Command routing
(Page 3 of 4 )
All of the built-in command objects use a class called RoutedUICommand, and you will normally use this if you define application-specific commands.* RoutedUICommand provides the mechanism for finding the right command binding when the command is invoked. This often needs to be determined by context. Consider Example 4-27 .
Example 4-27. Multiple command targets
<Grid>
<Grid.RowDefinitions>
<RowDefinition Height="Auto" />
<RowDefinition />
<RowDefinition />
</Grid.RowDefinitions>
<Menu Grid.Row="0">
<MenuItem Header="_Edit">
<MenuItem Header="Cu_t" Command="ApplicationCommands.Cut" />
<MenuItem Header="_Copy" Command="ApplicationCommands.Copy" />
<MenuItem Header="_Paste" Command="ApplicationCommands.Paste" />
</MenuItem>
</Menu>
<TextBox Grid.Row="1" AcceptsReturn="True" />
<ListBox Grid.Row="2">
<TextBlock Text="One" />
<TextBlock Text="Two" />
</ListBox>
</Grid>
If the focus is in the text box when theCopycommand is invoked, the text box handles the command itself as you would expect, copying the currently selected text to the clipboard. But not all controls have an obvious defaultCopybehavior. If the command were invoked while the focus was in the listbox, you would need to supply application-specific code in order for the command to do anything.RoutedUICommandsupports this by providing a mechanism for identifying the command’s target and locating the correct handler.
The target of theRoutedUICommandis determined by the way in which the command was invoked. Typically, the target will be whichever element currently has the focus, unless the command source’sCommandTarget has been set. Figure 4-4 shows the controls and menu from Example 4-27. As you can see from the selection highlight, the TextBoxat the top had the focus when the menu was opened, so you would expect it to be the target of the commands. This is indeed what happens, but it’s not quite as straightforward as you might expect.
Figure 4-4. Comand targets and focus
RoutedUICommand tries to locate a handler using a tunneling and bubbling system similar to the one used by the event system. However, command routing has an additional feature not present in normal event routing: if bubbling fails to find a handler,RoutedUICommandmay try to retarget the command. This is designed for the scenario where commands are invoked by user interface elements such as menu or toolbar items because these present an interesting challenge.
Example 4-27 is an example of this very scenario. It has a subtle potential problem. While the menu is open, it steals the input focus away from theTextBox. It’s unlikely that the menu item itself is the intended target for a command—it’s merely the means of invoking the command. Users will expect theCopymenu item to copy whatever was selected in theTextBox, rather than copying the contents of the menu item. The menu deals with this by relinquishing the focus when the command is executed. This causes the focus to return to theTextBox, and so the command target is the one we expect. However, there’s a problem regarding disabled commands.
A command target can choose whether the commands it supports are enabled. ATextBoxenables copying only if there is some selected text. It enables pasting only if the item on the clipboard is text, or can be converted to text. Menus gray out disabled commands, as Figure 4-4 shows. To do this, a menu item must locate the command target. The problem is that the menu is in possession of the keyboard focus at the point at which it needs to discover whether the command is enabled; the appropriate command target is therefore not the focused item in this case.
TheRoutedUICommandclass relies on focus scopes to handle this situation. If aRoutedUICommandfails to find a command binding, it checks to see whether the initial target was in a nested focus scope. If it was, WPF finds the parent focus scope, which will typically be the window. It then retargets the command, choosing the element in the parent scope that has the logical focus (i.e., the last element to have the focus before the menu grabbed it). This causes a second tunneling and bubbling phase to occur. The upshot is that the command’s target is whichever element had the focus before the menu was opened, or the toolbar button clicked.
If you are using menus or toolbars, you don’t need to do anything to make this work, becauseMenuandToolBarelements both introduce nested focus scopes automatically. However, if you want to invoke commands from other elements, such as buttons, you’ll need to define the focus scope explicitly. Consider Example 4-28.
Example 4-28. Without focus scope
<StackPanel>
<Button Command="ApplicationCommands.Copy" Content="_Copy" />
<Button Command="ApplicationCommands.Paste" Content="_Paste" />
<TextBox />
</StackPanel>
This associates two buttons with commands supported by aTextBox. And yet, as Figure 4-5 shows, the buttons remain disabled even when theTextBoxshould be able to process at least one of the commands.
Figure 4-5. Commands disabled due to missing focus scope
We can fix this by introducing a focus scope around the buttons, as Example 4-29 shows.
Example 4-29. Focus scope
<StackPanel>
<StackPanel FocusManager.IsFocusScope="True">
<Button Command="ApplicationCommands.Copy" Content="Copy" />
<Button Command="ApplicationCommands.Paste" Content="Paste" />
</StackPanel>
<TextBox />
</StackPanel>
Now when the buttons attempt to locate a handler in order to choose whether they are enabled, the presence of the focus scope will cause the command routing to look for the element with the focus. If theTextBoxhas the logical focus, it will become the command target. As Figure 4-6 shows, this causes the buttons to reflect the availability of the commands correctly, and it means they invoke the command on the correct target when clicked.
Figure 4-6. Command enabled thanks to focus scope
We don’t have to use focus scopes to solve the problem in this particular example. You can use the more explicit, though slightly cumbersome, approach shown in Example 4-30.
Example 4-30. Explicit command targets
<StackPanel>
<Button Command="Copy" Content="Copy"
CommandTarget="{Binding ElementName=targetControl}" />
<Button Command="Paste" Content="Paste"
CommandTarget="{Binding ElementName=targetControl}" />
<TextBox x:Name="targetControl" /> </StackPanel>
Here, each button specifies its command target explicitly. This makes it absolutely clear what the target will be. However, it is more verbose, so the automatic command routing is often more convenient. And even if the thought of manually specifying the command target for every item in a menu doesn’t strike you as unbearable, command routing has the added benefit of working well when there are multiple potential command targets (e.g., multiple text boxes on a form) and you want the command to go to whichever one last had the focus.
Next: Code-Based Input Handling Versus Triggers >>
More .NET Articles
More By O'Reilly Media
|
 This article is excerpted from Programming WPF, Second Edition, written by Chris Sells and Ian Griffiths (O'Reilly, 2007; ISBN: 0596510373). Check it out today at your favorite bookstore. Buy this book now.
|
|
