Processing Pointer Events
We now have all the pieces of the puzzle, so let's run through the processing of a pointer event from start to finish.
Pointer events are initially generated by the digitizer driver and passed to the window server. The pointer event is usually associated with a window whose on-screen region includes the pointer event. However, as we've just seen, pointer grab may be in use to associate the event with the same window that was associated with pointer down, or pointer capture may be in use to reject the event altogether.
The window is a member of a window group and the window group corresponds to an application. The window server sends the event to the relevant application. The control environment's CCoeEnv: :RunL() is called: it passes the event on to CCoeAppUi:: HandleWsEventL(). This is the same process that's used for the key events, and is also what we saw in the Chapter 4 debugger run through of Hellogui. HandleWsEventL() then identifies it as a pointer event associated with a particular window.
The control environment finds the window-owning control associated with that window and calls its (nonvirtual) ProcessPointerEventL() function. ProcessPointerEventL() calls Handle-PointerEventL() to handle the event. It also does some preprocessing, which I'll explain shortly.
HandlePointerEventL () is virtual: when implementing a simple control, you implement it to handle a pointer event, however you wish. If you don't implement this function, you get the default implementation (in the CCoeControl class), which searches through all the visible, non-window-owning component controls to find the one that includes the event coordinates, and then calls ProcessPointerEventL() on that control. This default implementation is good for compound controls and you override it at your peril.
So, the pointer event is ultimately channeled to the right noncom- pound control, where you can handle it by overriding HandlePointerEventL(). Note, however, that the complications we've already seen in this section affect both ProcessPointerEventL () and Handle-PointerEventL() :
■ The control environment's pointer-processing functions support pointer grab, so that once a pointer is grabbed, all subsequent events, to pointer-up, are channeled to the same control.
■ The control environment doesn't support pointer capture: you have to use windows (and window-owning controls) for that.
ProcessPointerEventL() implements the event reporting in the container needed for focus transfer between components: it generates interaction-refused events for dimmed controls, a prepare-focus-transition event for a focusable but nonfocused control on pointer-down, and a request-focus after HandlePointerEventL() has been called, for controls that were not refused focus at prepare-focus-transition time.
If you use the pointer buffer to capture high-resolution pointer event sequences, the control environment handles it with ProcessPointer-BufferReadyL(), and you have to handle it with HandlePointer-BufferReadyL().
Post a comment