Handling Pointer Events
Here's how COppFleetview handles pointer events:
void COppFleetView::HandlePointerEventL(const TPointerEvent&
aPointerEvent) {
// Check whether we're interested if(aPointerEvent.iType == TPointerEvent::EButton1Down &&
iData.iSeaArea.Contains(aPointerEvent.iPosition)) {
// Identify the tile that was hit
TInt x=(aPointerEvent.iPosition.iX-iData.iSeaArea.iTl.iX)/
iData.iTileSize; TInt y=(aPointerEvent.iPosition.iY-iData.iSeaArea.iTl.iY)/
iData.iTileSize; // Move cursor if necessary
TBool iCursorMoved=(x!=iCursorX || y!=iCursorY); SetCursor(x,y);
// Hit square unless it's already known if (iFleet.IsKnown(x,y)) {
iEikonEnv->InfoMsg(R_GAME_ALREADY_KNOWN); if (iCursorMoved)
DrawTilesNow();
else iData.iCmdHandler.ViewCmdHitFleet(x,y);
Like OfferKeyEventL () , HandlePointerEventL() is called on a control if the framework thinks the pointer event ought to be handled. Generally, that means the control is not dimmed or invisible, and it's the control with the smallest area that surrounds the coordinates of the pointer event. Unlike OfferKeyEventL () , HandlePointerEventL() requires the control to handle the pointer event or ignore it. The event is not offered to be consumed optionally; it will not be offered to any other control. That distinction is reflected in both the name (HandlePointerEventL()) and the return type (void).
As with keys, I can choose to handle the pointer event in one of three ways:
■ I can ignore it: I do this if it's not a pointer-down event, or if the event occurs outside the sea area on the game board.
■ I can handle it internally, in this case by moving the cursor : I do this here if the pointer event happens in a tile that has already been uncovered.
■ I can generate a command to be handled outside the control: I generate a hit-fleet command if the pointer event occurs in a tile that hasn't already been uncovered.
I'm using the pointer events to generate exactly the same command as I was with the key events - a hit request. So, I handle these commands using the same
MGameviewCmdHandler interface.
The TPointerEvent object passed to HandlePointerEventL () is defined in w32std.h as struct TPointerEvent {
enum TType {
EButtonlDown,
EButtonlUp,
EButton2Down,
EButton2Up,
EButton3Down,
EButton3Up,
EDrag,
EMove,
EButtonRepeat, ESwitchOn,
TType iType; // Type of pointer event
TUint iModifiers; // State of pointing device and associated buttons
TType iType; // Type of pointer event
TUint iModifiers; // State of pointing device and associated buttons
|
TPoint |
iPosition; |
// |
Window co-ordinates of mouse event |
|
TPoint |
iParentPosition; |
// |
Position relative to parent window |
You can check for the following:
■ Other buttons: you don't get these on pen-based devices.
■ Drag : is rarely used in Symbian OS but can be useful.
■ Move: you will never get this on pen-based devices. Devices supporting move also have to support a mouse cursor (which the window server does), control entry/exit notification, and changing the cursor to indicate what will happen if you press button 1. That's all hard work and adds little value to Symbian OS phones.
■ Button repeat : this is generated when a button is held down continuously in one place - it's just like keyboard repeat. It's most useful for controls such as scroll arrows or emulated on-screen keyboards.
■ Switch-on: some phones can be switched on by a tap on the screen.
■ Modifiers: state of the pointer event modifiers, including Shift, Ctrl, and Alt keys (where available) - using the same values as for key event modifiers. For instance in a text editor, Shift and tap is used to make or extend a selection.
Average user rating: 5 stars out of 1 votes
Post a comment