Chapter 1

� I don't have to 'consume' the key. I return a value (EKeyWas-Consumed or
EKeyWasNotConsumed) to indicate whether I consumed it.
The function starts by determining the kind of key event. There are three possibilities –
hardware key down, standard key, or hardware key up. Here, I'm only interested in standard
key events indicated by the value EEventKey being passed in the second parameter of the
function. I can handle the key in one of the three ways:
� I can ignore it if it's not a key that I recognize or want to use at this time.
� I can handle it entirely internally, within the control, by (say) moving the cursor, or (if it
were a numeric editor) changing the internal value and visual representation of the
number being edited by the control.
� I can generate some kind of command that will be handled outside the control, like the
hit-fleet command that's generated when I press the Confirm key when on a new tile, or
(if this were a choice list item in a dialog) an event saying that the value displayed in the
choice list had been changed.
For issuing commands from COppFleetView, I call
iData.iCmdHandler.ViewCmdHitFleet(), specifying the coordinates of the tile to hit.
iCmdHandler is of type MGameViewCmdHandler&, an interface class that I implement in
CGameController. I'll show the definition of the interface below.
Those are the main issues in key event handling. But you also need to know some of the
details about how to crack key events and key codes. The first parameter to
OfferKeyEventL() is of type TKeyEvent&, a reference to a window server key event
that's defined in w32std.h:
struct TKeyEvent
{
TUint iCode;
TInt iScanCode;
TUint iModifiers; // State of modifier keys and pointing device
TInt iRepeats; // Count of auto repeats generated
};
The legal values for iCode, iScanCode, and iModifiers are in e32keys.h.
� Use values from the TKeyCode enumeration to interpret iCode. The values are
=0xf800 for the usual function, arrow, menu, and other keys found on
PC keyboards. Although Symbian OS phones may have no keyboard, many of these
key events may still be generated using a front end processor (FEP).
� Use TStdScanCode and iScanCode for the extremely rare cases when scan codes
are of interest. The scan codes are defined by the historical evolution of IBM PC
keyboards since 1981. They originally represented the physical position of a key on the
81-key IBM PC keyboard, and have evolved since then to support new keyboards and
preserve compatibility with older ones. Since keyboards and keypads used on Symbian
OS phones are rather different, scan codes have limited value.
� Use TEventModifier to interpret the bits in iModifiers. This enables you to test
explicitly for Shift, Ctrl, and other modifier keys, where supported. These are of
particular interest in combination with navigation keys.
UIQ defines some additional key codes in quartzkeys.h. These represent the events
generated by the two or four direction keys on the keypad, and the Confirm key – they are
the key events that are consumed by COppFleetView::OfferKeyEventL(), above.