《Programming WPF》翻译第3章 2.处理输入

在Windows应用程序中，又3种基本的用户输入形式：鼠标、键盘和手写板。同时，还有一种更高级输入方式，其可能来自快捷键、工具栏的按钮、菜单项。

尽管控件担当着主要的输入对象，用户界面的所有元素都可以接受输入。不必吃惊，这是因为，为了提供外观，控件完全依赖于底层元素的服务，如Rectangle和TextBlock。因此，在用户界面内的元素类型中，所有的输入机制都是有用的，我们将要在接下来的章节介绍这些机制。

3.2.1 Routed事件

.Net框架定义了一个标准的机制来暴露事件。一个类可能暴露了一些事件，每个事件可能有任意数量的订阅者。虽然WPF也使用了这一标准机制，声称其克服了一个局限：如果一个正常.NET事件没有注册句柄，该事件将被视为无效并忽略。

考虑一下这对于一个典型的WPF控件意味着什么。大多数控件是由多个可视化组件组成的。例如，即使你为一个按钮添加了一个非常简单的可视化树，这棵树包括一个单独的矩形框，以及一条简单的文本，目前有两个元素：文本和矩形框。不管光标是否在文本或矩形框上，这个按钮都要响应鼠标点击事件。在标准.NET事件处理模型中，这意味着要为所有元素注册MouseLeftButtonUp事件。

更严重的是使用WPF内容模型。一个按钮并不局限于只有简单文本作为标题，它可以包含任意标签。示例3-2是一个相当普通的情况，但即使如此，其中仍然有6个元素：黄色的边框，代表眼睛的两个点，代表嘴的曲线，文本，以及作为背景的按钮本身。为每一个单独元素关联事件句柄关联，是烦冗而且效率低下的。幸运的是，这些并不是必需的。

图3-2

WPF使用routed事件，该事件比其他普通事件更为直接。原先的机制是，将委托句柄关联到激发该事件的元素，调用该句柄。如今，一个rounted事件会调用所有的关联到已知代码的句柄，从初始元素向上直到用户界面书的根元素。

示例3-1显示了图3-2中按钮的标记。如果Canvas中的一个Elliipse元素接收到输入，事件路由可以支持Button、Grid、Canvas和Ellispse接收事件，如图3-3所示。

示例3-1

图3-3

一个路由事件可以是bubbling，tunneling或Direct的。Bubbling事件以寻找附属到激发事件的事件句柄开始，接着寻找它的父级别，再接着是它的父级别的父级别，依次类推，直到达到这棵树的根，这个顺序是由图3-3的数字表明的。Tunneling事件以相反的方式工作。它先在树根寻找句柄，接着向下开始工作，以原始的元素作为结束。

Direct事件的路由方式与传统的.NET事件处理相同，只有直接附属到原始元素的句柄会被通知到。这典型地用于仅在它们的原始元素的上下文中有意义的那些事件。例如，如果鼠标的进入和移开是bubbled或tunneled的，这将是无用的。父级元素未必会关心何时鼠标从一个元素移动到另一个元素。在父一级元素，你可能希望“鼠标移开”意味着“鼠标已经离开了父一级元素”，因为使用了Direct事件路由，这才是它正确地意味着什么。一旦使用bubbiling，事件将有效的意味着“鼠标已经离开了这个元素，可能在或不在其父一级内的另一个元素中”。

除direct事件之外，WPF还定义了很多成对（bubbling和tunneling）的路由事件。Tunneling事件的名称通常以Preview开始，而且会首先被激发。这将给原始元素的父级一个看一下事件的机会，在到达其子级别之前（因此以“Preview”为前缀。）tunneling的Preview事件直接遵循bubbling事件。在大多数情形中，你将要处理bubbling事件，preview事件只用于你想要阻塞一个事件时，或者你想要父一级在正常处理事件时预先做一些事情。

在示例3-1中，大多数元素拥有事件句柄，由MouseLeftButtonDown和PreviewMouseLeftButtonDown事件指定相应的bubbling和tunneling事件。示例3-2显示了相应的后台代码文件。

示例3-2

using System;
using System.Windows;
using System.Diagnostics;

namespace EventRouting {
    public partial class Window1 : Window {
        public Window1(  ) {
            InitializeComponent(  );
        }

        private void MouseButtonDownButton(object sender, RoutedEventArgs e)
        { Debug.WriteLine("MouseButtonDownButton"); }

        private void PreviewMouseButtonDownButton(object sender, RoutedEventArgs e)
        { Debug.WriteLine("PreviewMouseButtonDownButton"); }

        private void MouseButtonDownGrid(object sender, RoutedEventArgs e)
        { Debug.WriteLine("MouseButtonDownGrid"); }

        private void PreviewMouseButtonDownGrid(object sender, RoutedEventArgs e)
        { Debug.WriteLine("PreviewMouseButtonDownGrid"); }

        private void MouseButtonDownCanvas(object sender, RoutedEventArgs e)
        { Debug.WriteLine("MouseButtonDownCanvas"); }

        private void PreviewMouseButtonDownCanvas(object sender, RoutedEventArgs e)
        { Debug.WriteLine("PreviewMouseButtonDownCanvas"); }

        private void MouseButtonDownEllipse(object sender, RoutedEventArgs e)
        { Debug.WriteLine("MouseButtonDownEllipse"); }

        private void PreviewMouseButtonDownTextBlock(object sender,
                                                     RoutedEventArgs e)
        { Debug.WriteLine("PreviewMouseButtonDownEllipse"); }

    }
}

每一个句柄输出了一条debug信息。这里时我们获得的debug输出，当点击Canvas中的TextBlock时。

PreviewButtonDownButton
PreviewButtonDownGrid
PreviewButtonDownCanvas
PreviewButtonDownEllipse
ButtonDownEllipse
ButtonDownCanvas
ButtonDownGrid
ButtonDownButton

输出结果证实了Preview事件是最先被激发的。还显示了它是从Button元素开始向下工作，正如我们对tunneling事件希望的那样。bubbling事件则从Ellispse开始向上工作。

Bubbling路由事件提供了很多事件，意味着你可以注册一个单独的事件处理在一个控件上，而且它将为内嵌在控件中的任何元素接收事件。你不需要任何特殊的处理以解决内嵌内容或自定义可视化内容，事件简单的向上冒泡，并且在那里可以全部被处理。

3.2.1.1中止事件处理

有很多情形你可能不想让事件冒泡。例如，你可能希望转换事件为别的什么东西，Button元素有效的转换了MouseLeftButtonDown和MouseLeftButtonUp事件为Click事件。它抑止了底层事件，从而只有Click事件冒泡到控件之外。

任何句柄都能防止进一步的处理路由事件——通过设置RoutedEvebtArgs的Handled属性，如示例3-4所示。

示例3-3

private void ButtonDownCanvas(object sender, RoutedEventArgs e) {
Debug.WriteLine("ButtonDownCanvas");
e.Handled = true;
}

另一个设置Handled标志的原因是，如果你想要防止正常的事件处理。一旦你在Preview句柄中这么做，不仅tunneling的Preview事件会停止，本应正常执行的bubbling事件也不会被激活，因此看起来似乎事件没有发生。

3.2.1.2确定目标

虽然在一个单独的地方，能够处理来自一组元素的事件，这是非常便利的，你的句柄可能需要知道是哪个元素引起激活一个事件，你可能想这正是句柄中sender参数的意图。事实上，sender一直将对象归诸于你附加到的事件句柄上。在使用bubbling和tunneling事件的情形中，这并不总是引起事件被激活的元素。在示例3-1中，ButtonDownWindow句柄的sneder是Window本身。

幸运的是，找到潜在的导致事件发生的元素，这是容易的。RouteEventArgs对象作为第二个参数传递，提供了一个OriginalSource属性。

3.2.1.3路由事件和正常的事件

正常的.NET事件（或者说，他们曾经称为CLR事件），提供了一个优势——相对于路由事件语法：很多.NET语言对处理CLR事件提供内嵌的支持。这就提供了最好的两种世界：你可以使用你喜欢的语言的事件处理语法，而不是利用额外的由路由事件提供的功能。

多亏了CLR事件机制的弹性设计。虽然这里有一种标准的联合了CLR事件的简单行为，CLR的设计者有远见的意识到，一些应用程序需要更多的高级行为。这些类因此可以自由的实现它们喜欢的事件。WPF获益于这种有CLR事件定义的设计——这些事件内在的作为路由事件来实现。

示例3-1和示例3-2安排了事件句柄的连接，通过使用标记中的属性。但是我们可能已经替代地使用了正常的C#事件句柄语法来关联构造函数中的句柄。例如，我们要在示例3-1中移除MouseLeftButtonDown和PreviewMouseLeftButtonDown属性，接着修改示例3-2的构造函数，如下面的示例3-4。

示例3-4

public Window1(  ) {
    InitializeComponent(  );

    this.MouseLeftButtonDown += MouseButtonDownWindow;
    this.PreviewMouseLeftButtonDown += PreviewMouseButtonDownWindow;
}

我们还能对来自内嵌元素的事件进行同样的处理。我们不得不应用x:Name属性为了能够访问C#的元素。

后台代码经常是最好的地方来附属事件句柄。一旦你的用户界面有不寻常和有创意的可视化外观，这是一个好的时机让xaml文件有效地被图形设计器拥有。一个设计者不应该知道开发者需要处理哪些事件，或者调用那些句柄函数。因此，你将通常要设计者在xaml中给元素命名，同时开发者将要在后台代码附属句柄。

3.2.2鼠标输入

鼠标输入关注于哪个元素直接位于鼠标下。所有的用户界面元素派生于UIElement基类，这个基类定义了大量的鼠标输入事件。这些事件列于表3-1中。

表3-1


Event	Routing	Meaning
`GotMouseCapture`	Bubble	Element captured the mouse.
`LostMouseCapture`	Bubble	Element lost mouse capture.
`MouseEnter`	Direct	Mouse pointer moved into element.
`MouseLeave`	Direct	Mouse pointer moved out of element.
`PreviewMouseLeftButtonDown`, `MouseLeftButtonDown`	Tunnel, Bubble	Left mouse button pressed while cursor inside element.
`PreviewMouseLeftButtonUp`, `MouseLeftButtonUp`	Tunnel, Bubble	Left mouse button released while cursor inside element.
`PreviewMouseRightButtonDown`, `MouseRightButtonDown`	Tunnel, Bubble	Right mouse button pressed while cursor inside element.
`PreviewMouseRightButtonUp`, `MouseRightButtonUp`	Tunnel, Bubble	Right mouse button released while cursor inside element.
`PreviewMouseMove`, `MouseMove`	Tunnel, Bubble	Mouse cursor moved while cursor inside element.
`PreviewMouseWheel`, `MouseWheel`	Tunnel, Bubble	Mouse wheel moved while cursor inside element.
`QueryCursor`	Bubble	Mouse cursor shape to be determined while cursor inside element.

UIElement还定义了一对属性，表示鼠标当前是否在元素上：ISMouseOver和ISDirectMouseOver。这两个属性的区别在于，当鼠标在正被讨论的元素上或任何它的子元素上时，前者为true；而后者仅当鼠标在正被讨论的元素上的时候才为true，不包括它的子元素这种情况。

注意到，上表中基本的鼠标事件设置不包括Click事件。这是因为Click一个高级别的概念——相对于基本的输入。一个按钮可以被点击——通过鼠标或键盘。此外，Click并不是必要的直接符合一个单独的鼠标事件。通常的，用户不得不点击或按下或释放鼠标，当鼠标在鼠标之上以注册一个Click事件时。相应地，这些高级别的事件由更明确的元素类型提供。Control类添加了一对事件：MouseDoubleClick和PreviewMouseDoubleClick。ButtonBase——Button的基类，CheckBox，RadioButton，都有添加这个Click事件。

如果你使用了一个Fill属性为透明的Shape，这个Shape将担当输入的目标，一旦鼠标在Shape之上。这回有一点令人惊讶，如果你使用了一个完全透明的笔刷。这个Shape将是不可见的，但是仍然作为输入的目标，不管鼠标在其上看来可能是什么样的。如果你想要一个填充为透明的Shape，而且不捕获鼠标输入，简单的根本不提供Fill属性，如果Fill属性为null值（而不是一个完全的透明笔刷），，这个Shape将不会担当输入的模板。

记住，如果你考虑处理一个鼠标事件的原因是，简单的为用户提供某些可见的反馈，写一个事件句柄可能过度了。这通常是可能的，通过声明性的属性触发器和事件触发器，可以在样式的标签中，完全达到你需要的可视化效果。

3.2.3键盘输入

键盘输入引入了focus的概念。不同于鼠标，没法为用户移动键盘在一个元素上，从而指出输入的目标。在Windows中，一个特定的元素被指定为拥有focus，意味着它会担当键盘输入的目标。用户通过点击鼠标或Alt+Tap 在正在讨论的控件上设置focus，或者通过使用导航键如Tab和指针。

原则上，任何用户元素可以获得焦点。IsFocused属性定义在UIElement——FrameworkElement的基类。尽管如此，Focusable属性决定了是否支持这个特征在任意特定的元素上。默认的，这个值对于控件是true；对其他元素是false。

表3-2显示了有用户界面元素提供的盘输入事件。所有的这些项使用tunnel和bubble路由，分别为Preview和主要事件。

表3-2


Event	Routing	Meaning
`PreviewGotFocus`, `GotFocus`	Tunnel, Bubble	Element received the focus.
`PreviewLostFocus`, `LostFocus`	Tunnel, Bubble	Element lost the focus.
`PreviewKeyDown`, `KeyDown`	Tunnel, Bubble	Key pressed.
`PreviewKeyUp`, `KeyUp`	Tunnel, Bubble	Key released.
`PreviewTextInput`, `TextInput`	Tunnel, Bubble	Element received text input.

注意到，TextInput并不是必要的键盘的输入。它代表了文本的输入在一个独立于设备的方式，因此这个事件也能被手动输入的结果所激活。

3.2.4手动输入

手写板上的铁笔以及其他支持手动输入的系统，有一套自己的事件。表3-3显示了手动输入事件——由用户界面元素提供。

表3-3


Event	Routing	Meaning
`GotStylusCapture`	Bubble	Element captured stylus.
`LostStylusCapture`	Bubble	Element lost stylus capture.
`PreviewStylusDown`, `StylusDown`	Tunnel, Bubble	Stylus touched screen over element.
`PreviewStylusUp`, `StylusUp`	Tunnel, Bubble	Stylus left screen while over element.
`PreviewStylusEnter`, `StylusEnter`	Tunnel, Bubble	Stylus moved into element.
`PreviewStylusLeave`, `StylusLeave`	Tunnel, Bubble	Stylus left element.
`PreviewStylusInRange`, `StylusInRange`	Tunnel, Bubble	Stylus moved close enough to screen to be detected.
`PreviewStylusOutOfRange`, `StylusOutOfRange`	Tunnel, Bubble	Stylus moved out of detection range.
`PreviewStylusMove`, `StylusMove`	Tunnel, Bubble	Stylus moved while over element.
`PreviewStylusInAirMove`, `StylusInAirMove`	Tunnel, Bubble	Stylus moved while over element but not in contact with screen.
`PreviewStylusSystemGesture`, `StylusSystemGesture`	Tunnel, Bubble	Stylus performed a gesture.
`PreviewTextInput`, `TextInput`	Tunnel, Bubble	Element received text input.

3.2.5命令

很多应用程序提供了多于一种的方式来执行确定动作。例如，考虑创建一个新文件的动作。你可以选择Fiel——New menu item，或者你可以点击相应的工具栏按钮。可选择的，你可以使用快捷键如Ctrl+N。如果应用程序提供了一个脚本系统，这个脚本还可以提供另一种执行这个动作的方式。结果是，无论你使用什么机制，都是一样的，因为这里有不同的方式调用同样的底层命令。

WPF对这个想法提供了内嵌的支持。RoutedCommand类代表了一个可以在多种方式调用的逻辑动作。在典型的WPF应用程序中，每个菜单项和工具栏按钮都联合到一个底层的RoutedCommand对象。

RoutedCommand以一种与底层输入表单非常相似的方式工作。当调用一个命令的时候，它激活了两个事件：PreviewExecuteEvent和ExecuteEvent。这些事件在这棵元素树中使用tunnel和bubble机制，和输入事件的方式相同。命令的目标是由命令的调用方式来决定。典型地，这个目标将会是当前有焦点的任何一个元素，但是RoutedCommand还提供了一个Execute的重载方法，这会传递一个明确的目标元素。

你可以从很多地方获取一个RoutedCommand。一些控件提供了命令。例如，ScrollBar控件为它的每个动作定义了命令，使之在静态字段有效，如LineUpCommand和PageDownCommand。然而，大多数命令并不是唯一对应到特定的控件。一些符合应用程序级别的动作如”新文件”或“打开”。其他动作会在控件上被调用，但是可以被一些不同的控件实现。例如，TextBox和RichTextBox都能处理剪切操作。

这里有一组提供了标准命令的类。这些类显示在表3-4中。这意味着你不需要创建自己的RoutedCommand对象来代表最普遍的操作。此外，很多命令被内嵌控件了解。例如TextBox和RichTextBox都支持很多标准的操作，包括clipboard，undo和redo命令。

表3-4


Class	Command types
`ApplicationCommands`	Commands common to almost all applications. Includes clipboard commands, undo and redo, and document-level operations (open, close, print, etc.).
`ComponentCommands`	Operations for moving through information such as scroll up and down, move to end, and text selection.
`EditCommands`	Text-editing commands such as bold, italic, and alignment.
`MediaCommands`	Media-playing operations such as transport (play, pause, etc.), volume control, and track selection.

3.2.5.1命令句柄

作为一个有用的命令，必须有事物对其进行响应。这个工作些微不同于处理正常的输入事件，因为大多数不是由控件定义的命令将会处理它们。表3-4中的类定义了95个命令，因此如果Control为每个截然不同的命令定义了CLR事件，那将需要190个事件——一旦还要包括preview的话。这不仅会极度不广泛，甚至还不是一个完全的解决方案。大多数应用程序在使用标准命令的同时，还定义了他们自身的自定义命令。明显的可选择性是为了RoutedCommand自身激活事件。然而，每个命令都是一个单件。例如，只有一个ApplicationCommand.New对象。如果你能直接添加一个句柄到命令对象，这个句柄会在任何时间运行。这个命令在你的应用程序任何地方被调用。如果你正想处理一个命令，当此命令在一个特定的窗口中执行的时候，会怎么样呢？

CommandBinding类解决了这些问题。一个CommandBinding对象映射了一个明确的RoutedCommand到一个句柄函数上——在一个特定的用户界面元素级别。正是这个CommandBinding会激活PreviewExecute和Execute事件，而不是UI元素。这些绑定保存在UI元素定义的CommandBinding属性。示例3-5显示了如何为一个窗体在后台代码文件中，处理ApplicationCommand.New命令。

示例3-5

public partial class Window1 : Window {
    public Window1(  ) {
        InitializeComponent(  );

        CommandBinding cmdBindingNew = new CommandBinding(ApplicationCommands.New);
        cmdBindingNew.Execute +=  NewCommandHandler;
        CommandBindings.Add(cmdBindingNew);
    }

    private void NewCommandHandler(object sender, ExecuteEventArgs e) {
        if (unsavedChanges) {
            MessageBoxResult result = MessageBox.Show(this,
                "Save changes to existing document?", "New",
                MessageBoxButton.YesNoCancel);

            if (result == MessageBoxResult.Cancel) {
                return;
            }
            if (result == MessageBoxResult.Yes) {
                SaveChanges(  );
            }
        }

        // Reset text box contents
        inputBox.Clear(  );
    }
}

这段代码依赖于命令路由的冒泡本质。顶级Window元素不同于成为命令目标的元素，当焦点通常属于某个窗体中的子元素时。然而，命令会向上冒泡到顶级。这个路由对命令的处理只放在一个地方，从而变得容易。

示例3-5处理的命令是ApplicationCommand.New。如果这组标准命令并没有满足你的应用程序的需要，你可以为明确的操作定义自定义命令。

3.2.5.2定义命令

示例3-6显示了如何定义一个命令。WPF使用对象实例来确定命令的唯一性。如果你要创建同名的第二个命令，这不会被当作同样的命令。由于这个原因，命令通常放置在静态字段或属性。

示例3-6

Example 3-6. Creating a custom command

public partial class Window1 : Window {

public static RoutedCommand FooCommand;

static Window1( ) {

InputGestureCollection fooInputs = new InputGestureCollection( );

fooInputs.Add(new KeyGesture

(Key.F,

ModifierKeys.Control|ModifierKeys.Shift));

FooCommand = new RoutedCommand("Foo", typeof(Window1), fooInputs);

}

在示例3-6中创建的Foo命令，通过一个CommandBinding被处理，正如任何其它命令一样。当然，用户某种调用这个命令的方式。

3.2.5.3调用命令

不仅定义了一个自定义命令，示例3-6还显示了一个将命令联合到用户输入的方法。配置这个特别的命令用来被一个特殊的输入表示所调用。当前支持两种输入表示类型：MouseGesture，是一个特别的由鼠标和触笔选中的形状；KeyGesture，正如在示例3-6中使用的，是一个特别的键盘快捷键。很多内嵌控件联合了标准的表示。例如，ApplicationCommand.Copy联合了标准的键盘快捷键，用来复制（大多数地方为Ctrl+C）。

虽然一个命令在创建的时候可以联合一组表示, 在一个特别的窗体的上下文中，你可能希望为这个命令分配另外的快捷键。为了允许这样做，用户界面元素有一个InputBindings属性。这个集合包含了InputBinding对象——联合了输入表示和命令。这些增加了联合了命令的默认表示。

输入表示如快捷键，不是唯一调用命令的方式。你可以在命令上调用Execute方法从而在代码上调用它。正如示例3-7所示，Execute被重载了。如果你没有传递参数，这个命令目标将会是任何得到焦点的元素，正如通过一个输入表示调用一个命令。但是你可以传递任何你想要的目标元素。

示例3-7

ApplicationCommands.New.Execute( );

ApplicationCommands.New.Execute(targetElement);

你可能想，要在菜单项和工具栏按钮的Click句柄中，编写这样的代码。尽管如此，由于命令经常联合于菜单项和工具栏按钮，Button和MenuItem都支持Command属性。这就唯一标志了要调用的命令，当元素被点击的时候。这里，为命令本身，提供了一种声明式的方式，而不是为每一个绑定到命令的UI元素提供一个句柄。示例3-8显示了一个联合了标准Copy命令的Button。

示例3-8

<Button Command="Copy">Copy</Button>

因为这个示例使用了来自ApplicationCommands类的标准命令，我们可以使用这个语法的简写形式，只需要指出命令名称。因为命令不是定义表3-4中的类定义的，这就需要一些更详细的信息。完整的命令属性xaml语法是：

[[xmlNamePrefix:]ClassName.]EventName

如果当前只有事件名，这个事件假定为标准命令中的一个。例如，Undo是ApplicationCommands. Undo的简写。否则，你必须提供一个类的名称，以及可能一个命名空间前缀。如果你正在使用自定义命令或者某个第三方组件定义的命令，这个命名空间前缀就是需要的。与Mapping这个XML处理指令（使外部类型在xaml文件中有效）协力工作。（参见附录A获取更多Mapping处理指令的信息。）

示例3-9显示了命令名称语法的使用——所有部分都在。M:MyCommand.Foo的值意味着当前正在讨论的命令是在mylib组件的MyLib.Commands.MyCommands类中定义的，并且存储在名为Foo的字段或属性中。

示例3-9

<?Mapping ClrNamespace="MyLib.Commands" Assembly="mylib"

XmlNamespace="urn:mylib" ?>

<Window xmlns:m="urn:mylib"

<Button Command="m:MyCommands.Foo">Custom Command</Button>

3.2.5.4支持命令

不仅可以被执行，命令还提供了一个QueryEnabled方法，返回了一个Boolean值表明命令是否能被立刻调用；某些命令仅在特定的上下文中有效。这个特征可以用来决定菜单或工具栏中的项是否应该变为灰色。调用QueryEnabled方法，会被以Execute同样的方式处理；CommandBinding对象用于处理这次查询。这个绑定激活一对PreviewQueryEnabled和QueryEnabled事件，这将以与PreviewExecute和Execute同样的方式进行tunnel和bubble。示例3-10显示了如何处理这个事件，为了系统定义的Redo命令。