. A particularly good choice for keeping models simple and minimizing the
modeling work was to base the language on convention rather than
con?¬?guration. For example, navigation by pressing the cancel button did
not usually need to speci?¬?ed at all.
. Specifying optional cancel navigation ?¬‚ow was restricted to a few UI elements
only. List, Multi_query, Pop-up, and Query were de?¬?ned to be possible sources
for cancel (with the Back relationship, see metamodel in Fig. 8.4). Only one
cancel per model instance was allowed.
. As the main UI controls (Form, Listbox, TextEditor) did not have a cancel
option, their navigation was based on closing the control or choosing from its
menu. The latter, closing the application from its menu, was speci?¬?ed in the
language by allowing menu items to also include a Stop object.
Rules that dealt with accessing phone services include the following:
. Every phone service allowed triggering one UI element or other phone service.
. Creating a new thread with Open as stand-alone was modeled similarly to the
others, but canceling it was not possible from the program calling the new
thread. This was also the case with starting external applications outside
Python??”their dialogs and other widgets could not be handled or synchronized
with the modeled Python for S60 application.
Pages:
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326