18.4  处理键事件

现在我们已经掌握了：

简单控件的成员函数OfferKeyEventL()中利用按键事件所完成的工作；

焦点的概念；

对话框，或者是当前聚焦的控件是如何处理键的；

控件如何使用或不使用提供给它的键。 这样，我们可以更好地理解窗口服务器和控件环境所处理的键分布的全部情况。

按下键时，先从键盘驱动器传递给窗口服务器。如果键是窗口服务器热键（例如Ctrl+Alt+Shift+K，它销毁与前台窗口关联的进程），则导致热键关联动作发生，并且它不会传递给任何应用程序。窗口服务器也管理了应用程序捕获的一个键列表—如果按键在列表中，它将被传递到应用程序中。

窗口服务器将大部分按键事件传递到前台应用程序中，在此处由 CCoeEnv::RunL()检测，并传递到CCoeAppUi::HandleWsEventL()，此函数将事件标识为按键事件，然后调用CCoe ControlStack:: OfferKeyL()。控件环境的控件栈（control stack）负责给将键提供给控件以做进一步的处理。

如果按键事件由屏幕上的虚拟键盘前端处理器生成，窗口服务器则不参与—前端处理器模拟键事件，将它直接传递给 CCoeAppUi::HandleWsEventL()，仿佛它来自于窗口服务器一样。手写识别前端处理器稍有不同 —它生成键事件，并将它们传递给窗口服务器，该服务器把它们添加到它的事件队列上。不过，在两种情况下，结果相同—键事件最终将处于控件栈上。

18.4.1  控件栈

在UIQ环境中，在控件栈上一般有5种类型控件（其他的用户界面也类似）：

调试键控件，这是一个不可见控件，它利用所有“Ctrl+Alt+Shift+某个键”组合（例如，Ctrl+Alt+Shift+R让当前屏幕完全重绘）；如果调试键控件不利用该键，则进一步由栈接受；

需要拦截键事件的激活的前端处理器，大部分前端处理器拥有一个控件，它与其他可见控件相比，以更高的优先级添加到控件栈上，确保前端处理器拥有对接收到的所有按键事件的优先的决定权；在 UIQ中，虚拟键盘前端处理器需要位于控件栈上—当它激活时，利用除了那些自身生成的所有按键事件。手写识别前端处理器不使用任何键事件，因此不处于控件栈上；

激活的对话框，键将被提供给位于顶层的激活对话框，它使用该键。仅当无对话框激活时，这些键才进一步提供给控件栈；

菜单栏，在一些 UI 中（非 UIQ），菜单栏需要处理应用程序定义的快捷键；当菜单栏不可见时，它将只使用快捷键以及能使它显示的键。相反，当菜单栏可见时，则使用提供给它的所有键；在控件栈中，菜单栏处于任何对话框的下面，因此当对话框激活时，将阻止调用菜单栏；

应用程序视图，当应用程序视图不可见时，通常应当忽略键（因此也不能使用它们），否则，如果可见，应当处理和使用它们。

图18.4显示了应用程序的控件栈，该应用程序具有3个视图（其中一个被激活）、1个激活的前端处理器和2个激活的嵌套对话框。

按键事件先按优先级次序（由高到低），再按栈次序（同一优先级内，由最近添加者到最早添加者）提供给控件栈。图 18.4 所示的优先级在coeaui.h的枚举里定义。使用栈结构，Symbian操作系统或程序员可以在GUI环境中插入新对象，而不必重写控件环境或现有的GUI组件。

栈上的控件处理键的准确方式取决于控件。对话框是一般的容器，我们已经见过了它们如何为组件控件提供键。应用程序视图通常也是容器，它们使用自己的逻辑，至少包含一些对话框使用的格局，为组件控件提供键。调试键控件是无任何组件的单个控件：它可以使用键，也可以不使用。

一个可见的菜单至少包含两个控件—菜单栏和菜单面板—可能还有更多的控件，因为可能有子菜单。菜单为这些控件提供并处理键以实现传统的菜单导航以及菜单项的选择。

不同类型的前端处理器以不同方式处理按键事件。UIQ的虚拟键盘前端处理器在激活时使用大部分按键事件，但并不处理它们。其他的前端处理器完成复杂的处理来组成输出字符串，以交付给下层的应用程序。带预测的文本输入的前端处理器或者支持远东文本输入的前端处理器是这样的例子。