Wiley.Symbian.OS.C.plus.plus.for.Mobile.Phones.Aug.2007 (779890), страница 70
Текст из файла (страница 70)
mifconv is then usedto package the SVG-T icons into a Multiple Images (or Multi-Icon) File(MIF); a corresponding MBM file is generated only if there are bitmapicons amongst the source icons.Further details are available in the S60 SDK or on Nokia’s website.13.4 Updating the Resource FilesBefore you can rebuild your application with its new icons, you need toupdate some of the resource files to ensure that the icons are included inthe build.Each application requires a localizable application information file,usually named <application-name>_loc.rss. This is specified inthe application registration file (see Section 13.5).The application information file contains a resource, LOCALISABLE_APP_INFO, specifying a caption for your application to bedisplayed in the application launcher, the number of icons in the iconfile, and the location of the icon file.
For example:// OandX_loc.rss//// ¤ Symbian Software Ltd 2005. All rights reserved.//#include <AppInfo.rh>RESOURCE LOCALISABLE_APP_INFO{caption_and_icon ={CAPTION_AND_ICON_INFO{caption = STRING_r_oandx_caption;number_of_icons = 3; // each icon must be bitmap/mask pairicon_file = "\\Resource\\Apps\\oandx.mbm";}};}378RESOURCE FILESThe string resource is a text resource defined in the resource fileOandX.rss.13.5Application Registration FilesOne of the major changes in Symbian OS v9.1 is the introduction ofthe application registration file.
Since GUI applications are now EXEs(rather than APPs as in pre-v9 versions), the application registration file isused to tell the application architecture that this particular EXE is a GUIapplication. Application registration files contain information about anapplication’s name, UID and properties that is required by the applicationlauncher or system shell. All applications must provide a registration file.A registration file is a standard Symbian OS compiled resource file(RSC). The RSS file used to build the registration file should be given thesame filename as the application, but with a _reg suffix; this replacesthe Application Information File (AIF) supported on earlier versions. Theregistration file must build into a private data-caged directory belongingto the application architecture server, since the application architectureis ultimately responsible for launching all applications.
Putting the RSSfile in a private directory prevents a malicious application replacing anexisting application’s RSS file with a spoof version.As an example, here’s OandX_reg.rss:// OandX_reg.rss//// Copyright (c) 2006 Symbian Software Ltd. All rights reserved.#include <appinfo.rh>#include <OandX.rsg>//specify the UID2 and UID3 valuesUID2 KUidAppRegistrationResourceFileUID3 0xE04E4143RESOURCE APP_REGISTRATION_INFO{app_file = "OandX";localisable_resource_file = "\\resource\\apps\\OandX_loc";}This example specifies localizable application information as a resource within the application UI resource file. Localizable applicationinformation can also be provided in a separate resource file, as discussedpreviously.
The APP_REGISTRATION_INFO structure minimally needsto provide the name (but not extension) of the application binary (usingthe app_file statement). If a localizable application information fileis provided, as in this example, its full path and filename must bespecified, excluding the drive letter and file extension. This file definesLOCALIZABLE STRINGS379the application’s captions and the name of the icon file.
By convention ithas the same filename as the application, but with a _loc suffix.To build the registration file and the localizable application file, addthe following lines to the application’s MMP file:// V9 application registration fileSTART RESOURCE \OandX_reg.rss#ifdef WINSCWTARGETPATH\private\10003a3f\apps#elseTARGETPATH\private\10003a3f\import\apps#endifENDSTART RESOURCETARGETPATHLANGEND\OandX_loc.rss\resource\appsSCThe registration file is used by the application architecture server,which has a SID of 0x10003a3f. The import subdirectory allows anapplication to write files into a second application’s private data directory,providing that it knows the second application’s SID.In our MMP file, the TARGETPATH value ensures that registrationfiles are correctly deployed to the application architecture’s private datacaged area.
On the emulator (WINSCW), all registration files are locatedin \private\10003a3f\apps. This is also true on real hardware forregistration files built into the ROM, but for applications installed ontoa phone using the standard software installation method, data cagingprevents writing to this directory. The registration files are thereforeinstalled into \private\10003a3f\import\apps, and the applicationarchitecture retrieves them from there.
In all cases, the registration filemust be located on the same drive as the application.13.6 Localizable StringsIf you intend to translate your application into one or more differentlanguages, there are some additional things to bear in mind. A translatorwill not necessarily be a programmer and will probably find it difficult topreserve the general structure of a resource script through the translationprocess. For this reason alone, it is good practice to store all resource textstrings in a separate resource localizable string (RLS) file, with a .rlsextension. An RLS file defines symbolic identifiers for strings, to whichthe resource file refers when it needs the associated string.All you have to do is to replace each text string in the resource scriptwith a symbolic identifier and, in a separate file, associate the identifierwith the original string.380RESOURCE FILESAs an example, consider the following two resources:RESOURCE MENU_PANE r_edit_menu{items={MENU_ITEM{command = ECmd1;txt = "Item 1";},MENU_ITEM{command = ECmd2;txt = "Item 2";}};}...RESOURCE TBUF r_text_info{buf = "Information text message!";}The three text strings in these resources would appear in an RLS file asfollows:rls_string STRING_r_edit_menu_first_item "Item 1"rls_string STRING_r_edit_menu_second_item "Item 2"rls_string STRING_r_message_info "Information text message!"The keyword rls_string appears before each string definition,followed by a symbolic identifier, and then the string itself in quotes.The resource file itself is then modified to include the RLS file (in thiscase, assumed to have the name application.rls) and to refer to thestrings via their symbolic names:#include "application.rls"...RESOURCE MENU_PANE r_edit_menu{items={MENU_ITEM{command = ECmd1;txt = STRING_r_edit_menu_first_item;},MENU_ITEM{command = ECmd2;LOCALIZABLE STRINGS381txt = STRING_r_edit_menu_second_item;}};}...RESOURCE TBUF r text_info{buf = STRING_r_message_info;}You can include C- or C++-style comments in the text localization fileto inform the translator (and yourself!) of the context in which each textitem appears, and to give information about any constraints, such as themaximum length permitted for a string.
There is a double advantage: thetranslator sees only the text and the comments, and the programmer seesa resource script free from comments that could disguise the structure ofa resource.There is no specific convention about the file name extension to beused for text localization files. At Symbian, developers tend to use a .rlsextension but S60 suggests the use of a .loc extension.Multilingual ApplicationsAs described in Chapter 11, you specify multiple language options bymeans of a LANG statement in the application’s MMP file. The LANGkeyword is followed by a list of two-character codes, one for eachlanguage, for example:LANG 01 02The codes can be anything you like, but are normally taken from thetwo-digit values specified in the TLanguage enumeration ine32const.h.The Symbian OS build tools use the LANG statement to build theapplication’s resource files once for each code in the list.
For each build:• a LANGUAGE_XX symbol is defined• the built file is given a .rXX extensionwhere XX represents the language code for that build.You should include the appropriate RLS files in each of the application’slocalizable resource scripts, for example:// application_loc.rss#include <AppInfo.rh>382RESOURCE FILES#ifdef LANGUAGE_01#include "appenglish.rls"#elif defined LANGUAGE_02#include "appfrench.rls"#endifRESOURCE LOCALISABLE_APP_INFO...In this case, the result of the build is to generate two resourcefiles, named application_loc.r01 and application_loc.r02,respectively containing English and French text. The SDK documentation explains how to use the application’s PKG file to build a number of language-specific resource files into a multilingual application’sreleasable SIS file.If an application’s MMP file does not contain a LANG statement, theresource script is built only once and the resulting resource file is given a.rsc extension.
Effectively, this means that the default LANG statement is:LANG SCFor simplicity, all later discussions of building resource files consideronly the default case.13.7Multiple Resource FilesA single resource file supports up to 4095 resources, but a Symbian OSapplication may use multiple resource files, each containing this numberof resources. The application identifies each resource by a symbolic IDcomprising two parts:• a leading 20 bits (five hex digits) that identify the resource file• a trailing 12 bits (three hex digits) that identify the resource (hence the4095-resource limit).The leading 20 bits are generated from the four-character name specified in the NAME statement in the resource file.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
