Wiley.Symbian.OS.C.plus.plus.for.Mobile.Phones.Aug.2007 (Symbian Books), страница 101

Duringearly development of Symbian OS, the GUI and the control environmentwere rewritten twice to get these issues right.Explaining these things is only slightly easier than designing them!18.1Key, Pointer and Command BasicsThe basic functions that deal with interaction are HandlePointerEventL()and OfferKeyEventL(). In Chapter 15, we showed howthese functions were implemented in COandXAppView, the interactiveheart of the Noughts and Crosses application.We can handle pointer and key events in three ways (as can be seenby closer examination of the way that Noughts and Crosses works):• we can ignore an event if it is not a key that we recognize or want touse at this time or if it is not a pointer-down event; another reason forignoring a pointer event would be if the part of the control that wasclicked on was not one that could respond to pointer events• we can handle an event internally within the control, by, for example,moving the cursor or (if it was a numeric editor) changing the internalvalue and visual representation of the number being edited by thecontrol or, for a pointer event, by drawing something at the locationof the click• we can generate some kind of command that is handled outside thecontrol; for example, a choice-list item in a dialog may respond to anup- or down-arrow key event by saying that the value displayed in thechoice list has been changed; the Noughts and Crosses applicationresponds to a pointer event by passing a request to play in a tile to thegame engine.In some cases, a key press to a control may be interpreted as a commandto the application that has a wide-ranging effect on an application’s stateor it might affect a control or view in a very different part of the applicationto itself.

A way to handle such commands is to define an M class, a mix-ininterface, that can be implemented by a central class in the applicationand used by every control that might want to call such a command.USER REQUIREMENTS FOR INTERACTION55918.2 User Requirements for InteractionFrom the preceding discussion, it should be apparent that it is nothandling pointer and key events that makes programming an interactivegraphics framework complex.

Rather, it is handling the relationshipsbetween different parts of the program, and the visual feedback you givein response, that can cause difficulty.Here are some user requirements, expressed in non-technical terms.First, the user needs to be able to understand what’s going on. Considerthe S60 screenshots in Figure 18.1. In Figure 18.1a, the action is takingplace in the menu, which is in front of everything else; the window thatwas previously in the foreground is faded.

In Figure 18.1b, the field wherethe action is taking place is highlighted: it looks different to the otherfields and there is a cursor (which flashes).(a)(b)Figure 18.1 An S60 application showing a menu (left) and a text editor (right)Secondly, the user should not be able to enter invalid data throughthe dialog.

If the user presses Done, when a value in a numeric editoris outside the valid range, the dialog should complain that the value isinvalid, and should not carry out the action associated with Done. Thedialog should stay active, with the highlight on the offending field. InFigure 18.2, if the alarm time is set after the start time of the meeting, thehighlight is returned to the alarm time field and a message is put up to tellthe user what is wrong.

When an invalid field value is entered, the usershould be notified; for example, if 14 is entered for the hour value of thealarm, it is reset to 12. If the user presses Cancel, the dialog should closewithout carrying out any validation.560GRAPHICS FOR INTERACTIONFigure 18.2An S60 application showing a numeric editorA third requirement is that the user should not be able to enter data thatis inconsistent with other settings in the dialog. In Figure 18.3, if the userclicks on the Day: item the click is ignored because it makes no sense toset a day when the alarm is for the next 24 hours; this is indicated by theDay: item being shown dimmed out. If the user changes the When: itemto a value where a day is required, the Day: item should automaticallybecome active and be redrawn.Figure 18.3 A UIQ application showing a dimmed controlSOME BASIC ABSTRACTIONS56118.3 Some Basic AbstractionsBased on the list of user requirements, you can see some abstractionsbeginning to take shape.• The highlight (or, in a text editor, the cursor) is a visual indicationof focus.

The control that currently has focus receives the majorityof key events; it ought to know whether it has focus or not anddraw any necessary highlight accordingly. (Not all key events goto the control with focus: the hardware Confirm key causes thedefault button – usually Done – to be pressed, rather than going to thehighlighted control.)• A control needs to be able to refuse interactions such as pointer events.Invisible or dimmed controls should certainly refuse interactions.

Acontrol should know that it is dimmed and draw itself in a suitable way.• A control needs to be able to say whether itis in a valid state and torespond to queries about its state.• If a control’s state changes, it needs to be able to report that to anobserver, such as the dialog, so that it can handle any knock-oneffects.These are the user requirements. Throughout the rest of this chapter, wedescribe how the GUI framework makes it possible for you to meet them.Programmer RequirementsIf ease of use matters to end users, it certainly matters to programmerswho have some requirements concerning the way these ideas shouldhang together.• It should be possible to invent new dialogs with rich functionality andto implement the validation rules with sufficient ease that programmerswant to use these facilities to deliver helpful and usable dialogs.• It should be possible to use any control in such dialogs – not onlythe stock controls provided by Uikon, S60 or UIQ, but also any newcontrol that you wish to include in a dialog.

(Not all controls aredesigned to be included in dialogs: there’s unlikely to be a need toinclude COandXAppView in a dialog.)• It should be possible to write code that supports only the thingsyou require for a particular control, without having to worry aboutimplementing things that are unnecessary. Furthermore, you needto be confident that you have included only those things that needincluding and excluded only those things that need excluding.562GRAPHICS FOR INTERACTIONCompound ControlsWe introduced the idea of compound controls in relation to drawing.Compound controls also make it very much easier to implement generalpurpose containers such as dialogs. Figure 18.3 shows a variety of controlswithin the same dialog:• a title• a help icon• captioned control arrays, including numeric editors, text editors anddrop down lists• a button group, with two buttons (Save and Cancel).As these controls are all together it makes it much easier for a changein one control to cause another control to be updated in response.Key Distribution and FocusHere is a simplified account of how a dialog processes OfferKeyEventL()(for more details, search for OfferKey EventL()in the SDK).At any one time, precisely one of the controls in the captioned controlarray has focus.

That means the line is highlighted or displays a cursorand is the recipient of most key events. When the dialog is offered a keyevent, it handles some special cases itself (for instance, it offers Confirm tothe dialog buttons) but otherwise it offers the key to the general-purposecontrol in the currently focused control.A general-purpose control is one that can be used both in dialogs andapplication views. To make a control intended for dialogs usable in anapplication view is not always difficult and it is a good thing to aim for.To make a control intended for application views usable in a dialog israrely necessary and you shouldn’t try to do so without good reason.There are plenty of special cases, but this description is enough toillustrate the role of focus and to begin to show why keys are offered butwhy they are not always consumed.It is important to give a clear visual indication of focus and all thecomponents work together to achieve this:• the dialog is the topmost window: it has focus merely by being there• the buttons and the title bar can never receive focus, so they don’tneed to change their drawing code in response to whether they’refocused or notSOME BASIC ABSTRACTIONS563• the general-purpose control designed for use in a dialog should<b>Текст обрезан, так как является слишком большим</b>.