John.Wiley.and.Sons.Rapid.Mobile.Enterprise.Development.for.Symbian.OS.An.Introduction.to.OPL.Application.Design.and.Programming.May.2005.eBook-LinG (779881), страница 14
Текст из файла (страница 14)
For any menu item thatyou don’t want to have a hot key you can specify a value less than orequal to 32 instead. This always applies to mCASCs. Here, we’re usingthe value 16.Here’s our menu code, now with a cascading menu option called"More" that appears as the last entry in the first menu card:mINITmCASC "More","Option 5",%e,"Option 6",%fmCARD "Convert","Option 1",%a,"Option 2",%b,"More>",16mCARD "Edit","Option 3",%c,"Option 4",%dMenuResult%=MENU(LastMenu&)66A CONVERSION PROGRAM: EVENT CORE IN PRACTICEFigure 4.1ABP menu screenSeries 80 MenusSeries 80 is the closest to a PC or Mac menu on Symbian OS. You canhave as many menu cards as can be accommodated on the screen, andwhile menu cascades can be used, there should be enough room on thecards for all your menu options. See Figure 4.1.Menus are called up by pressing the Menu key, and this will bepicked up in PROC KeyboardDriver:.
Hot keys are shown, and theyshould follow the Series 80 style guide. A link to this can be found onwww.symbian.com/books/rmed/rmed-info.html.Series 60 MenusSeries 60 does not have specific menu keys, therefore you should hardcode the CBA1 button to call the menu. Generally, Series 60 applicationsshould use the left soft key (CBA1) to call a menu or do an action,and the right soft key (CBA2) to go back/undo an operation or exit theapplication. When you call a Series 60 menu, you will not see the titleof any menu card, and only the first menu card is shown – any othersare ignored. You are encouraged to use one level of cascading menus formore options.Hot key values are not shown on the menu but are still used inthe underlying OPL code as the return value for the selected menuitem – this means our ActionHotKey: procedure will still work.
Youshould always have "Exit" as the last option in a Series 60 menu.UIQ MenusUIQ menus can only be called by a pen tap on the screen. This is pickedup in the PROC PointerDriver: procedure, where the menu PROC iscalled, and the resulting command is passed to PROC HotKey:.UIQ applications generally have two menu cards, one named after theapplication and one called 'Edit'. Note that the value of constants meansour menu card can use the KAppName$ string constant:FIRST STEPS WITH EVENT CORE67mINITmCARD KAppName$,"Option 1",%a,"Option 2",%bmCARD "Edit","Option 3",%c,"Option 4",%dMenuResult%=MENU(LastMenu%)If you program more than two menu cards, then you will see thesemenu cards until there is no more room on the screen.
Hot keys arenot shown, but as with Series 60 they’re still used in the underlyingOPL code.UIQ applications do not normally have an exit command, insteadthey respond to commands from the system to close down when morememory is needed. These messages are handled by the System CommandHandler Procedure in our main event loop. The drop down ‘views’list on the right-hand side of a UIQ menu bar is not implementedin OPL.4.1.6 Putting Together Menu Code for Each UIWhen programming your menus, you have to consider what UI you willbe using. If you know the program will only run on one Symbian OS UI,then you only need to use the relevant menu system.If the .opo file is designed to run on more than one platform, then youneed to define the menu system in such a way that the correct style isused.
In PROC Init: we set the variable Platform% to determine theUI we were using (1=Series 80, 2=Series 60 and 3=UIQ). This gives ussomething like:mINITIF Platform%=KPlatformSeries80%mCASC "More","Option 5",%e,"Option 6",%fmCARD "Convert","Option 1",%a,"Option 2",%b,"More>",16mCARD "Edit","Option 3",%c,"Option 4",%dELSEIF Platform%=KPlatformSeries60%mCARD KAppName$,"Option 1",%a,"Option 2",%b,"Option3",%c,"Option 4",%dELSEmCARD KAppName$,"Option 1",%a,"Option 2",%bmCARD "Edit","Option 3",%c,"Option 4",%dENDIFMenuResult%=MENU(LastMenu%)While we do not check for Platform%=KPlatformGeneric% (anunrecognized UI), it will default to using the UIQ menu (Platform%=KPlatformUIQ%) of two menu cards.
This is another example ofprogramming with an eye to what can go wrong (i.e. someone runningOPL on a device with a new screen size).68A CONVERSION PROGRAM: EVENT CORE IN PRACTICE4.1.7 The Convert MenuSo, now we know how to set up a menu, let’s put one into action for ourconversion program.Sketch it OutAs with all programming, we’ll sketch out what we want the program todo, then put this into a structured format before going ahead and codingthat section.There are some menu options that you should always considerfirst – the defaults, as it were.
These are:• About• Exit (although this option should not appear in UIQ applications)• Preferences.Add to this the four conversion operations we’ll want to show:• temperature• long distance• short distance• weight.And we have the options we want to appear on our menu system.Show the CodeLet’s look at the two variants of menu code. The first as if we are codingfor only one UI – let’s look at the UIQ version:mINITmCASC "Units","Temperature",%t,"Long distance",%l,"Shortdistance",%d,"Weight",%wmCARD "Convert","Units>",16mCARD "Edit","Preferences",%c,"About",%aMenuResult%=MENU(LastMenu%)While we’ve used the Menu Cascade option here when it isn’t trulyneeded, there is scope on how to add in new options that will requirethere to be this cascade in place.If we were to do a ‘multiple UI’ version, the code would look like this:mINITIF Platform%=KPlatformSeries80%rem Series 80FIRST STEPS WITH EVENT CORE69mCARD "File","Exit",%emCARD "Convert","Temperature",%t,"Long distance",%l,"Shortdistance",%d,"Weight",%wmCARD "Tools","Preferences",%c,"About",%aELSEIF Platform%=KPlatformSeries60%rem Series 60mCASC "Units","Temperature",%t,"Long distance",%l,"Shortdistance",%d,"Weight",%wmCARD "Convert","Units>",-16,"Preferences",%c,"About",%eELSErem UIQ Menu (also Default)mCASC "Units","Temperature",%t,"Long distance",%l,"Shortdistance",%d,"Weight",%wmCARD "Convert","Units>",16mCARD "Edit","Preferences",%c,"About",%aENDIFMenuResult%=MENU(LastMenu%)4.1.8 Gathering and Presenting Information – DialogsWe’ve now seen many ways to get input from a user through the use ofmenus and key presses (mainly through hot keys).
There are two moreways to take input. Directly from a pen tap on the screen, and gatheringinformation from dialogs.We’ll look at pen taps in the next chapter, but for now let’s look atdialog boxes.Why have Dialogs?Dialogs are designed to show information to the user, and gather information from the user. They are a two-way process. In Convert, we’ll usea sequence of dialog boxes that will firstly get the number we want toconvert and secondly show the result.One advantage of dialogs is that as a programmer you do not need toworry about how the dialog box works. You don’t need to worry aboutreading the keyboard, or processing any handwriting recognition.
TheOPL Runtime will do this for you. This means that when constructing adialog box you can be confident that it will work on any of the UI versions.The OPL Runtime will also lay out the dialog box and give it a similarlook to other dialog boxes on that UI. This makes dialog boxes a powerfultool for cross-platform programming.Showing Info – the About DialogLet’s start off with a simple dialog box – one to show a simple Aboutscreen. See Figure 4.2. Here’s the OPL code:dINIT "About "+KAppName$"dTEXT "","by "+KAuthorName$,2 KgPrintBLeftAligned%dTEXT "","by "+KAuthorEmail$,2 KgPrintBLeftAligned%LOCK ON :DialogResult%=DIALOG :LOCK OFF70A CONVERSION PROGRAM: EVENT CORE IN PRACTICEFigure 4.2Convert about dialogue boxConstructing a DialogCreating and displaying your dialog is very similar to creating anddisplaying a menu.
You initialize the dialog, build up the elements, andthen show the dialog (while reading the result if appropriate). You thenadd elements to your dialog box, one line of code at a time. These willbe added to the dialog box in the order that they appear in the code. Inthe example above we have two text lines in our dialog box (all Dialogelements are prefixed with a ‘d’).Finally, we display the dialog box with the DIALOG command. Aswith the MENU command, DIALOG will return a value depending onhow we exit the dialog box (if you wanted you could use the DIALOGcommand on its own without recording the value, but this is regarded asbad programming practice).Looking up Commands (dTEXT and DIALOG)As with all OPL commands, understanding the syntax of a command willgive you more than enough knowledge to implement a command notdescribed in any of these chapters. Every OPL command is listed, withsyntax and a short description in the Appendix of this book, and thatshould always be your first port of call for learning new commands.FIRST STEPS WITH EVENT CORE71Dialog commands are probably the easiest to understand, so let’sbreak down the dTEXT command with help from the Appendix.
Here’sthe entry for dTEXT:**************************************************************************dTEXTDefines text to be displayed in a dialogUsage:ordTEXT p$,body$,t%dTEXT p$,body$Defines a line of text to be displayed in a dialog.p$ will be displayed on the left side of the line, and body$ on theright side. If you only want to display a single string, use a nullstring ("") for p$, and pass the desired string in body$.
It will thenhave the whole width of the dialog to itself. An error is raised ifbody$ is a null string and the text line is not a separator (see below).body$ is normally displayed left aligned (although usually in the rightcolumn). You can override this by specifying t%:Alignment of body$ is only supported when p$ is null, with the bodybeing left-aligned otherwise. In addition, you can add any or all of thefollowing three values to t%, for these effects:Specify this item as a text separator. p$ and body$ must both be thenull string for this to take effect. The separator counts as an item inthe value returned by DIALOG.These constants are supplied in Const.oph.See also dEDIT, dINIT.**************************************************************************There are two ways we can type the dTEXT command in our source code,dTEXT p$,body$ or dTEXT p$,body$,t%.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
