Handling TUI User Input (Windows CE 5.0)
The TUI classes work together to respond when the user interacts with the application by pressing a context or keypad button, using the touch screen, lifting the handset, and so on.
In general, the CVoIPApp class handles all user input, generally by forwarding messages to the appropriate object.
As an example, suppose the user is viewing the Call Logs screen. This screen displays a menu that enables the user to view the received, dialed, and missed call logs.
The user presses the OK context button. TUI has registered this button as a system-wide hotkey, using the Windows CE RegisterHotkey function. Because of this registration, pressing the OK context button generates a WM_HOTKEY message.
The WM_HOTKEY message is then processed as follows:
The CVoIPApp instance receives the WM_HOTKEY message, determines that the message represents a context button, and dispatches the message to the CVoIPDesktopManager instance.
The code in CVoIPDesktopManager checks to see if there are active UI elements that would be the target for this event — like a popup menu. If there are not, CVoIPDesktopManager knows that the OK button is associated with the main dialog and dispatches it to the CVoIPMainDialog instance.
The CVoIPMainDialog instance checks the current state and forwards the message to the corresponding IVoIPState implementation.
In this scenario, the current screen is Call Logs, so the message is forwarded to the state the controls screens that display menus, menu state, which is defined in MenuState.cpp (and MenuState.h).
The IVoIPState implementation takes the appropriate action given that the OK context button was pressed.
In the case of the Call Logs screen, this probably involves using the CVoIPStateMgr class to change to a new IVoIPState instance that represents one of the call logs.
These steps are taken when the CVoIPMainDialog owns the primary UI. If a special-purpose dialog is active, that dialog owns the screen and is responsible for drawing itself and responding to all user input.
Keyboard events are sent directly to the window that has the focus and do not go through the steps outlined above.
For detailed information about these classes, see TUI Object Model. For a discussion of the asynchronous nature of the TUI application, see Asynchronous Operations in the TUI.
See Also
Examining the TUI Implementation
Send Feedback on this topic to the authors