Chapter 1

Figure 12.4
Key events are offered down the control stack, firstly in order of priority (highest to lowest),
and secondly in stack order (most recently added to least recently added, within each
priority). The priorities shown above are defined in an enumeration in coeaui.h.
Using this stack structure, Symbian or an application programmer can insert something new
into the GUI environment without having to rewrite the control environment or the existing
GUI components.
Exactly how a control on the stack handles a key event depends on the control:
� Dialogs are general containers, and we've already seen how they offer keys around
their component controls.
� App views are often also containers, and they will use their own logic, including at least
some of the patterns used by dialogs to offer keys to component controls.
� The debug keys control is a single control without any components – it either
consumes a key, or it doesn't.
� The menu bar, when visible, includes at least two controls – the menu bar and a menu
pane – and possibly more, since there may also be cascaded menus. The menu bar
offers and handles keys among these controls to implement conventional menu
navigation and item selection.
� Most FEPs need to handle key events but how they do this depends on the type of
FEP. UIQ's virtual keyboard FEP when active, consumes all key events but the ones it
generates itself. FEPs activated by a key press or combination of key presses need to
be on the control stack even when they are inactive, but when inactive they would
typically not consume any other key events.
We can see again how focus and key handling are usually – but not always – related: