手势功能

自 2002 年第一批 Windows Mobile 设备问世以来，触摸屏已经成为该设备的代名词；不过，据称 Windows Mobile 6.5 才是第一个向开发人员公开所有形式手势支持的版本。那么什么是手势，它又为何如此风靡？

Windows Mobile Professional 设备的传统触摸屏提供的是鼠标模拟图面，它通过屏幕驱动程序接口生成鼠标左键和鼠标移动消息。在处理和传送这些消息时，屏幕和触笔就像实际的鼠标一样，它们之间存在一定的相似性：鼠标与屏幕上的触笔一样，以线性方式产生一系列位置坐标，都可用作非常精确的指针设备。

两者之间也有一些区别。比如，鼠标发送的位置信息与按钮信息无关，而触摸屏总是模拟按下的左键，仅在发生屏幕接触时才发送位置信息。只要触摸屏与鼠标保持足够的相似性，此模式就仍然有用武之地。然而，随着现代话机屏幕的不断增大，用户食指已然迅速变成最自然而直观的触笔。在个人消费市场上，精度要求和易失性都比较高的触笔很快就会过时，取而代之的是对粗犷的交互式界面的需求，这种界面会勾起消费者的触摸冲动，促进与用户之间的情感联系。

与触笔笔尖的精确度要求形成鲜明的对比，手指活动提供了一种不同的操作模式，它与鼠标输入截然不同。输入数据不再是精确定位的，线性输入轨迹往往更接近于绕月轨道而非直线。区别不仅在于数据；输入结果也应产生与输入序列相符的平滑动态响应。现在，鼠标模式显然已不再适用，我们需要一种不同的新模式来帮助描述这种输入并了解其响应方式。答案就是手势。

不仅仅是触摸手势

在详细了解触摸手势之前，我们先在更宽泛的层面思考一下一般意义上的手势。手势可包括许多不同的动作。它可以是计算机屏幕上的手指移动，而且就像挥动手臂或与别人握手一样，摇头甚至也算得上是一种手势（姿势）。依我看来，只将屏幕输入视为唯一手势来源似乎有点狭隘。当今的许多设备都有多种传感器，其中包括触摸屏、加速感应器、罗盘、GPS 装置及照相机等。摇晃、翻转、旋转设备，甚至对着镜头微笑都可以解释为需要软件进行响应的手势（姿势），而这些仅仅是我们目前所知传感器能够识别的手势。

Windows Mobile 6.5 中的体系结构在设计上考虑到了这一点，因此将手势来源及识别过程与该手势的路由、传送和响应分开。虽然目前我们只有触摸手势识别功能，但一旦具备相应传感器和识别组件，就可以通过系统提供新的手势。新的传感器和识别软件可由硬件制造商添加，并集成到现有手势传送体系结构中，　　图 3 五种核心手势

您可能会奇怪为什么要使用其中的一些手势，因为鼠标行为似乎已足以获取相同的信息。比如，选择手势就像单击按钮一样，而平移手势就像鼠标移动一样。这五种手势的重要性体现在两个方面。

一致性：系统通过两个消息接收鼠标点击操作：鼠标按钮按下和弹起。识别点击操作的具体行为是识别该操作的控件所特有的功能。比如，当鼠标按钮按下和弹起的位置都位于窗口边界内时，按钮控件会将这两个动作识别为一次点击。相比之下，ListView 控件对其列表中的每一项也会识别同样的事件。选择手势通过使用一致的参数，使其识别独立于控件。用于手势识别的距离阈值可识别分辨率（或者更准确地说，可识别到点/英寸），并且是为使用最广泛的指形（手指形状范围异常广泛）而设的。因此，可在大小不同的屏幕上使用相同的物理距离，从而在设备之间提供一致性。

路由：手指不是准确指针设备，当用户在移动或走动中时尤为如此，因此应用程序需要最大化可触摸目标区域，这一点至关重要。手势传送组件借助特定的规则完成此任务，从而提升了这些简单手势的价值。

路由

手势信息通过新的 WM_GESTURE 消息进行传送，而且该消息与所有窗口消息一样，也有包含消息详细信息的关联参数 DWORD wParam 和 LONG lParam。WM_GESTURE 消息参数包含手势 ID 作为 wParam 以指示要传送的手势，并包含完整手势信息的句柄作为 lParam。鼠标消息总是发送到鼠标坐标位置所在的最顶层窗口（不包括鼠标捕获情形），但对于手势来说，这些规则将有所不同。手势消息与之不同，它们总是发送到构成完整手势序列的第一个触摸点相应的最顶层窗口。对于屏幕移动距离容差很小的选择、按住和双选手势来说，这一细微差异的影响不大。但对于平移手势，差别就很大了。在开始平移时，所有平移消息都会发送到开始平移时所在的窗口，即使平移移动使触摸点移出原始窗口也如此。

同样，滚动手势的识别位置也会从其原始触摸点延伸到许多像素的距离。但将滚动消息路由到与上述平移消息相同的窗口中比较合理，因为用户在该原始控件中启动输入序列并打算以其作为目标。鉴于平移手势通常与直接操控有关（即像在桌面上移动纸张一样在屏幕上移动内容），因此此路由非常合理，因为在屏幕上移动内容期间，在最初触摸时指下的控件或屏幕点应始终保持在指下。

未处理的消息路由

手势消息路由的另一个不同寻常的方面是对未处理手势消息所采取的操作。与所有未处理的消息一样，它们最终也被发送到 DefWindowProc 以进行默认处理。当 DefWindowProc 收到手势消息时，它会尝试查找当前窗口的父窗口并将该消息发送到该父窗口。这样做可最大限度地扩大可供用户使用的可触摸区域。

为便于解释，请考虑一个包含一些子标签控件的可滚动窗口。父窗口实现平移和滚动手势响应逻辑，从而在可视图面中上下移动子标签控件。不过，这些标签控件未发生修改，对手势支持一无所知。如果用户手势碰巧始于触摸标签控件而不是父窗口，该用户也可获得相同的结果，也就是窗体将相应地移动以响应输入移动。通过将未处理的手势消息从标签控件转发到父窗口，满足了用户的期望，内容移动的效果就像用户直接触摸窗体一样。手势消息

Windows Mobile 6.5 可识别五种手势，而应用程序可接收七种手势。额外的两种手势是在手势序列开始和结束时发送的 BEGIN 和 END（所有手势类型都带有前缀 GID_ 以指示手势标识符，因此这两种手势的标识符是 GID_BEGIN 和 GID_END）。例如，如果识别选择手势，则应用程序会收到三个手势消息：GID_BEGIN、GID_SELECT 和 GID_END。对于以滚动手势为结果的平移序列，应用程序会收到 GID_BEGIN、GID_PAN、GID_PAN…、GID_SCROLL 及最后的 GID_END。

GID_BEGIN 十分有用，因为它包含原始触摸点的屏幕坐标。GID_END 可方便地指示何时用户输入已结束并且不再为当前序列发送手势。