In the Getting Started Guide Series, we introduced the basics of Symbian OS. Next, we will introduce more knowledge to understand how to write programs. The main content of this article is to introduce mobile phones based on Symbian OS, how to do relevant documents and directories. That is, some of the main information in the mobile phone, such as address book, notepad, and task, SMS information, picture file, sound file ... before introducing the above, first, let's briefly understand the hardware system of Symbian OS, these hardware Directly related to our specific operations of its data. Compared with a typical desktop computer, the hardware of the Symbian OS machine clearly has more restrictions, bringing us more inconvenience to our software development, but also adds more market opportunities. The main part of the Symbian OS phone: A CPU: Symbian OS CPU is 32bit, the speed is low, and the existing mainly based on 190MHz and 206MHz Strongarm CPU, some is based on ARM9. One ROM: ROM also exists on our PC, but the ROM on the PC contains only a small start load program and BIOS, and the ROM in the Symbian OS is mapped to Z: disk. All content in the ROM can be accessed as a folder on the Z: disc, or you can read data directly from the ROM. The ROM on Symbian OS is approximately 20MB. System RAM: RAM is mainly used for active programs and system kernels, and is also used as a disk space used as a C: disk access, but the RAM of the general machine is only 8MB or 16MB, so it is likely to be exhausted RAM resources. I / O device: It may be a handwritten input display, a compact keyboard, or a memory card (as D: disk access), or other connection port, infrared and Bluetooth ... Power supply: including the main battery and external power supply . With the approval of the Symbian OS parts, you have to talk about the information data we will operate: contact, notepad, and tasks, SMS information, image files, sound files ... These information data is mainly stored on mobile phones. In the RAM, it can be performed by accessing the C: disc.
Below we focus on the way of operation of the directory and document: First introduce a class: TPARSE has learned, the main function of this class is to process the path, first see a code: ------------ ------------------------ _Lit (Kpath, "C: ///Meeting.wrd"); ... TPARSE P; P. Set (kpath, null, null); p.Name (); // gives "meeting" p.NameAndext (); // gives "meeting.wrd" ... ------------ ---------------------- Through the above example, the function of TPase should have a certain understanding, and this class is used to handle the relevant paths. Information collection.
Of course, it also has the functions of the two paths, as follows: ----------------------------------_Lit ( Kspec, "A: File1"); _LIT (Krelated, "C: //path 1/Related.xxx"); TPARSE FP; fp.set (kspec, & krelated, null); --------- ------------------------ The result of the above operation is A: /PATH1/File1.xxx Tip: When we need to extract some necessary paths When information is required, we need to use the TPARSE class to operate this path to achieve the purpose. This class will be used frequently when processing the path! ! Operating folder: Specify an absolute path such as: Specify_LIT (KbitmapFolder, "C: //////////////////////////////////////////////////////////////////////////////////////////////////////////////> This way is simple and easy, and in most Nokia's mobile phones, it is often possible to be completely feasible. But in order to enhance the portability of the program, don't use the absolute path. Because we have a second method: PathInfo class: We can get the memory path of the current device through this class. For example: root directory: Pathinfo :: phoneMemoryRootPath () Storage image file directory: PathInfo :: imagespath () Storage installation SIS file directory: PathInfo :: installspath () Storage Sound Directory: PathInfo :: Soundspath () If you want to locate MMC This additional memory should be like this: #include
Enumerate the files under a folder: ---------------------------------- TBUF <50> Path , TPath; TBUF <256> FileName; RFS ISESSIONRFS; CDIR * DIRLIST; // Number, Name and File Size_Lit (Kstringsize, "% S% S"); user :: leaveiferror (iSessionRFS.Connect ()); PATH = PathInfo :: PhoneMemoryRootPath (); path.Append (PathInfo :: PicturesPath ()); // picture folder User :: LeaveIfError (iSessionRFs.GetDir (path, // read file folder information KEntryAttMaskSupported, ESortByName, dirList )); Tint J = dirlist-> count (); // File number for (Tint i = 0; i . S contents The bitmask determines which file and directory entry types should be listed The sort key determines the order in which they are listed Notes:.. If sorting by UID (ESortByUid is OR'ed with the entry sort key), then UID information will be included in the listing whether or not KEntryAttAllowUid is specified in anEntryAttMask. The function sets anEntryList to NULL, then allocates memory for it before appending entries to the list. Therefore, anEntryList should have no memory allocated to it before this function is called, otherwise this memory will become orphaned. The caller of this function is responsible for deleting anEntryList after the function has returned. Parameters const TDesC & aName Name of the directory for which a listing is required. Wildcards may be used to specify particular files. TUint anEntryAttMask Bitmask Indicating the attributes of intert. Only Files and Director whose Attributes Match Those Specified Here Can Be Included in The Listing. for more information see KEntryAttMatchMask and the other directory entry details. Also see KEntryAttNormal and the other file or directory attributes. TUint anEntrySortKey Flag indicating the order in which the entries are to be sorted. This flag is defined in TEntryKey. CDir * & anEntryList On return contains A List of Directory and File Entries. Return Value Tint Kerrnone if successful, Otherwise another of the system-wide error cots. ------------------------- -------------------------------------------------- ----- The above introduction is taken from SERIES 60 2.1 Help. The main way of use is that the user gives a PATH, which is the first parameter const tdesc & aname, by calling, the content in this folder returns to the fourth parameter cdir * & anenTryList, which is stored next this list. The content is the file information under this folder, as for the middle two parameters to set some shield information, so that the user can take out the file information you need. Find the corresponding document: ----------------------------------- Tfindfile File_Finder (ASESSION); // 1 CDIR * file_list; // 2 Tint Err = file_finder.FindWildBydir (AWildName, Ascandir, File_List); // 3 While (Err == Kerrnone) {Tint i; for (i = 0; i So you must delete the CDIR object. 10. Finally, you can also use tfindfile :: FildWild () to continue to check the next drive. -------------------- -------------------------------------------------- ---------- With the above introduction, you must have a certain understanding of the operations in the Symbian OS, more more detailed use methods or you need you to read the Symbian OS SDK corresponding help file. The routines given above are debugged under VC 6.0 / s60 SDK 2.1. Article Source: http://symbian.org.cn/bbs/viewtopic.php? T = 883