Chapter 1

Some commands can be executed immediately, given only their ID. An Exit command exits
the application. (If the application has unsaved data, we don't ask the user: we simply save
the data. If the user didn't want to exit, all that is needed is to start the application again.)
Other commands need further UI processing. A Find command, for example, needs some
text to find, and possibly some indication of where to look. Handling such commands
involves dialogs, which are the subject of Chapter 10.
Not all input to applications comes from commands. If you type the letter X into a word
processor while you're editing, it doesn't generate a command, but a key event. If you tap on
an entry in an Agenda, it doesn't generate a command, but a pointer event. Handling pointer
and key events is the business of the app view and other controls in the application. After a
chapter on drawing to controls (Chapter 11), I cover key and pointer interaction in Chapter
12.
Some key and pointer events are captured by controls in the Uikon framework and turned
into commands. Later in this chapter, we'll get a glimpse into how the menu and shortcut key
controls convert these basic UI events into commands.
The declaration of CHelloGuiAppUi in HelloGui_AppUi.h is as follows:
class CHelloGuiAppUi : public CQikAppUi
{
public:
void ConstructL();
~CHelloGuiAppUi();
private: // from CEikAppUi
void HandleCommandL(TInt aCommand);
private:
CHelloGuiAppView* iAppView;
};
As is usually the case, the second-phase constructor and the destructor reveal who owns
what:
void CHelloGuiAppUi::ConstructL()
{
CQikAppUi::ConstructL();
iAppView = CHelloGuiAppView::NewL(ClientRect());
}
CHelloGuiAppUi::~CHelloGuiAppUi()
{
delete iAppView;
}
Again, this class is derived from the UIQ CQikAppUi class, rather than the Uikon
CEikAppUi equivalent, but as with the application class, there is no significant difference in
the implementation.