Familiarization with Symbian Diaries (2 ))

[Options menus]
Avkon menu items are generated from the menu bar and menu pane resources specified in the RSS file. In Windows, the simulator can be started by pressing F1 or using the options custom function key, which is implemented by using eaknsoftkeyoptions ID. If the application Program To switch to pre-existing 'Options, use r_avkon_softkeys_options_back as the CBA resource.
The options of each menu are defined in the menu_pane resource structure and used in system, application, view, and context.
For example, the following menu resources:
Resource menu_pane r_system_menu
{
Items =
{
Menu_item {command = ecmdcut; TXT = "cut ";},
Menu_item {command = ecmdcopy; TXT = "copy ";},
Menu_item {command = ecmdpaste; TXT = "Paste ";},
};
}
The sub-menu is specified by the 'cascade 'parameter. Below is a column sub-
Menu_item {command = esystemoptions; TXT = "System Options ";
Cascade = r_system_options_menu ;}
As the name suggests, this specifies the sub-menu of r_system_options_menu above.
Combining menu sections
Menu sections is integrated by menu_bar resources. In the ascending order.
A typical column is
Resource menu_bar r_menuapp_menu
{
Titles =
{
Menu_title {TXT = "system"; menu_pane = r_system_menu ;},
Menu_title {TXT = "app"; menu_pane = r_app_menu ;},
Menu_title {TXT = "View"; menu_pane =
R_view1_options_menu ;},
Menu_title {TXT = "context"; menu_pane = r_context1_menu ;},
};
}
In this way, all Application menus are listed.
Note that the TXT option is only used for identification and is not displayed at all. But it must be in the resource file.
The default menu bar uses the eik_app_info resource and is loaded at startup. If you are using the view architecture, you can set the menu in the view resource structure.
Changing menu sections
When the program is running, you can change the menu item at will, just call:
Ieikonenv-> appuifacloud ()-> menubar ()-> setmenutitleresourceid (menu_bar_resource_id)
This is done every time you need to change the content, so you need to prepare all the menu resources that may be used in advance:
)
Note: If the view system structure is used, use the view's own menu system. The following operations should be performed:
Imyview-> menubar ()-> setmenutitleresourceid (menu_bar_resource_id)
Changing menu items
You can also change individual menu items so that you can add or delete menu items anytime, anywhere.
The application UI should overload the following virtual functions:
Void dyninitmenupanel (tint aresourceid, ceikmenupane * amenupane)
Under what circumstances should this function be called? When all secitons have been added to the menu, the menu pane object has been created.
The application UI can also reload the following virtual function:
Void dyninitmenubarl (tint aresourceid, ceikmenubar * amenubar)
The avkon scroll indicator is in the middle of softky pane. In addition, softkey pane is created or deregistered because of the appearance or disappearance of "popped-up" controls. Communication between controls with the current visible scroll indicator is managed by the caknenv created in the system, which is used by softky pane and ceikscrollbarframe.
This mechanism is hidden from programmers. In general, we don't need to worry about this scrollers.
Ensure correct scrolling Control
1, using listboxes with caknpopuplist
Void csimpleappui: createpopupselectionl (tint aitems, tbool atile)
{
Ceiktextlistbox * List = new (eleave) ceiktextlistbox;
Cleanupstack: pushl (list );
Caknpopuplist * popuplist = caknpopuplist: newl (list,
R_avkon_softkeys_ OK _back); // softkey pane created here
Cleanupstack: pushl (popuplist );
List-> constructl (popuplist, ceiklistbox: eleftdowninviewrect );
// Scroller referennce fetched from (now existing) softkey pane here:
List-> createscrollbarframel (etrue );
// Set the visibility of the scrollbars (this Code may become redundant)
List-> scrollbarframe ()-> setscrollbarvisibilityl (ceikscrollbarframe: eoff,
Ceikscrollbarframe: eauto );
InsertCode
Popuplist-> executeld (); // popup selection list is put up
Insert Code
Cleanupstack: Pop (); // popuplist
Cleanupstack: popanddestroy (); // list
}
Other writing knowledge:
1. the exit of the application and eeikcmdexit are in an avkon program. There are two ways to help you exit the program. One is the exit menu option and the other is the back function key, there is a slight difference between the two methods. Let's talk about it below.
Any program can end the program by calling exit () in response to eeikcmdexit. Similarly, some controls such as dialogs, menus, and popup lists can reply to the escape key to exit.
What to do
Applications and views use the handlecommandl () function to process commands sent from menus and function keys. Handlecommandl () must be able to process the command ID eeikcmdexit, which is a signal to exit the current program.
In this case, typical app UI processing should call saveanychangesl () and exitl (). Note: If you are writing a view system program, views or app UI can process these commands, but they cannot be processed at the same time. Otherwise, problems may occur.
When the back function key is pressed, The handlecommandl () function also receives the eaknsoftkey command ID. How to handle this command depends on the context environment. But if we do want to exit, we have to treat it as if we have accepted eeikcmdexit.
The function key back may always generate the eaknsoftkey ID, while the menu option exit will always generate the eakncmdexit command ID. Note that this is different from eeikcmdexit and is not directly used.
How it works
The exit () function will cause the exit of the current program. If the program is embedded, the control will be handed over to the parent window. In avkon, we want to run the back function key, but exit will close all windows, including the parent window. The closing mechanism also requires that the corresponding sub-Window application be closed. This is a chain reaction. To do this, you can send the eeikcmdexit command ID to each related program. Therefore, the program should respond to the eeikcmdexit and eaknsoftkeyback commands when calling exit. Framework will trigger the process when eakncmdexit is detected.
This means that you use the eakncmdexit command ID in your resources, but you should respond to the eeikcmdexit command ID in handlcommandl.
Dialog Shutter
The dialogs and popup windows of the application can be closed by using dialog shutter.
Embedded applications
Exit and exit
As mentioned above, exit and back are different. They are revealed when embedded programs appear.
App UI pointers
When you embed a program, all programs share a ceikonenv instance. Note that the member function eikonenv: eikappui always returns the app UI pointer in the innermost part. Therefore, if you write a component that needs to access the app UI, you must decide whether you want to access the innermost app UI.
If you are always accessing the innermost app UI, use ceikonenv: eikappui ().
How to use it is to call this function to obtain the app UI when your object is being constructed, and then store it in the data member for future use.
If you want to access the root app UI, you should loop through list of container app UIS.
Ceikappui * root = this;
While (root-> containerappui ())
Root = root-> containerappui ();
INI files
By default, avkon does not process INI files. If your program needs to do this, it will get a not supported error. If you want your program to support INI files, you must reload the openinifilec () function,
Ieceikapplication: openinifilelc ().
The following is an example:
Cdictionarystore * cclkapplication: openinifilelc (RFS & AFS) const
{
Return ceikapplication: openinifilelc (AFS );
}
Documents files
Avkon does not support document file generation by default (when cakndocument is used as the base class of the program document ). If you need
If you need a document, you must reload the openfilel (tbool adoopen, const tdesc & afilename, RFS & AFS) function.
Cfilestore * ctestdocument: openfilel (tbool adoopen, const tdesc & afilename, RFS & AFS)
{
Return ceikdocument: openfilel (adoopen, afilename, AFS );
}
AIF files
Each program should have its own information file (AIF file), which contains bitmaps and related program titles. If our program requires different bitmaps and languages, it is provided by multiple versions of this document. There are two language codes.
Avkon can generate different titles (using AIF) for each language as needed and define their resource structure in apcaptionfile. RH.
For example:
# Include "tstappcaption. Loc"
# Include
Resource caption_data
{
Caption = tst_app_caption_string;
Export caption = tst_app_short_caption_string;
}
The title resource file should be named _ caption. RSS. The compiled resource file should be in \ System \ apps \ % appname % \ appname_caption.rxx. Here XX is a two-digit digital language code (in the MMP file)
-----------------------------------------------------------------------
The Symbian system requires a high level of exception handling because it is designed for small memory application models. Therefore, in actual use, insufficient system resource allocation may occur, this requires that our program design comply with the requirements of the Symbian rules.
All functions that can cause abnormal exit should end with a letter l at the end of the function name, and exit abnormally through the "abnormal exit function" and send it back through the call stack, until it is captured by the exception capture module. This module is generally implemented by the main function e32main () of the console-type application, or provided to the graphic user interface (GUI) program as part of the application framework.
Note that we do not need to provide any capture module. Generally, the system will provide it in an appropriate place. We only need to add an L suffix after the function that may cause exceptions.
The newl () and newlc () implementations of the class are very interesting. If the object is pointed by the member variable, newl () can be used to generate the object, if it is directed by a custom variable, you need to use newlc (). Here the C suffix specifies to create a new instance of a class on the hybrid stack and push it into the clear stack, if the memory is insufficient, the system exits unexpectedly. (Generally, the suffix "C" indicates that the function pushes the pointer to the created object to the stack before returning it .)
As we have mentioned above, we generally do not need to capture exceptions. If we really want to write, we need to use traps and trapd macros. Normally, we pass the exception to the active sched, but a new problem arises. The activation scheduler deletes the independent variables of the called function, but what if there is a pointer to the objects allocated on the stack at this time? If you delete it rashly, it will cause memory leakage. Therefore, some mechanisms are required to retain these pointers so that they can be released after an exception exits. Symbian OS provides a mechanism to solve this problem in clearing stacks.
Stack clearing is such a stack that contains pointers to objects to be released when an exception occurs. This sentence is very important. We also understand why the custom pointers to the allocated objects use Class C processing. (Note: Class C objects in Symbian OS are always allocated on the heap and cbase is always used as their most basic base classes .)
The other reason we know that the object pointer pointed by the member variables does not need to be pushed into the stack clearance is that the destructor of these functions already have the processing to delete objects, if the stack is to be removed, the object will be deleted twice.
During the learning process of Symbian, we found that the embedded operating system is indeed quite different from ordinary programming. Its handling of exceptions and Its careful processing of memory are staggering. My general vague understanding of exceptions is (not yet complete) Source code First, add the L suffix to the function that may cause abnormal exit. At this time, leave it to the exception capture system for processing, or write this trap harness by yourself, the specific order is that when an exception occurs, the system does not return an error code, but directly exits unexpectedly. At this time, the system will call User: Leave (), when we call it, we can get to the exception capture module of the function. In general, we have no need to write this trap harness, and the Symbian framework will provide it at the right place, what we need to do is add the suffix L after the name of the function that may cause the exception to exit to ensure exception handling.
Generally, an exception occurs when the allocated space is insufficient. For example, in the new operation, we should do so. Symbian uses a parameter to call new, new (eleave). With it, an error occurs when the memory is allocated, so we can exit unexpectedly.
For example
Csomeobject * myobject = new csomeobject;
If (! Myobject) User: Leave (kerrnomemory );
You can replace it
Csomeobject * myobject = new (eleave) csomeobject;
We can do this for an object, but for a composite object, if one member pointer points to another object, when constructing this object, how can we ensure correct abnormal exit without memory leakage when the sub-object fails?
The knowledge points of Bidirectional construction are involved here. In general, the solutions are given in the newl and newlc functions, and the two are different. If a member variable is used to point to the object to be modified, we should use the newl function. If it is a custom variable, we should use the newlc function, because newlc can push the object into the clear stack to exit correctly when there is insufficient memory, that is, the C suffix indicates that the pointer pointing to the created object is pushed into the cleanup stack. The difference between newlc and newl is that LC does not have the final cleanupstack: Pop () function, and l has, it finally comes up with the concept of clearing the stack.
Trap mainly looks at the SDK, very helpful,
Trap (_ r, _ s) {ttrap _ t; If (_ T. trap (_ R) = 0) {_ s; ttrap: uptrap ();}}
We execute _ s in an exception capture. This is a C ++ segment .. _ R must be a tint value. I have read this definition of singed Int. That is, Int. 32-bit. In addition, you must first declare it. In the macro field, on the contrary, trapd does not need to be used. It is declared internally, and the rest is the same. If any c ++ segment exits abnormally, the return value of exit is assigned to _ r (in fact, it is returned from user: Leave) as mentioned above, when an exception occurs, the system calls User: leave. We can see that the sequence of the exception is from language to user: Leave to trap ), otherwise, it is the value of kerrnone.
At this time, the system usually prepares a clear stack for the c ++ segment. If any language in _ s encounters an exception, the objects in the clear stack will be cleared.
Although trap harness is good, it should not be used in large quantities. From the perspective of the size and speed of executable code, the cost of this item is very high. If it is not used properly, it may lead to Missing errors. Generally, trap is used only when l is added to the last part of the method name to allow abnormal exit. It is not a better choice.
When checking whether the memory has been leaked, we 'd better use the _ assert_dubug macro for testing, which can prevent many problems and detect parameters and pointers in functions without restrictions. But only in debug mode.
Cmyclass: function (cting * athing)
{
_ Assert_debug (athing, panic (emyappnullpointerinfunction ));
}
This statement indicates that when the value of athing is false, emyappnullpointerinfunction is called. This is what should be done when the pointer is null :)
Traditional Symbian programs inherit the custom view controls from ccoecontrol. These custom controls are stored in the Control Stack and are created, cleared, or hidden based on the needs of the program.
There is also a view structure. The biggest difference between this structure and the traditional structure is that it does not use the View Management System of the system. Of course, this can be regarded as its advantage, after all, view architecture has many limitations.
For technical implementation, view switching is achieved by creating, clearing, and changing the visibility of the main view control. Specifically, we store a large number of controls in the Control Stack to locate the key events on each control. The dialog box structure is generally a dialog box in the main view. The view model that plays a major role is a number of dialog boxes. Compared with the traditional structure, we do not need to re-compile the C ++ code, but only need to modify the resource file to change the layout.
Note that, if you do not use the nested dialog box with caution, the nested dialog box will occupy a considerable amount of stack space.
Note that avkon has the automatic Status Pane processing function built into the multi-page dialog box, which is different from the other two structures, the operation is guided by the labels in the Navigation Pane.
If you want to use the dialog box structure, you 'd better design it to run it in the form of a modal dialog box.
The use of the design Main Dialog Box usually requires the entire customer area, there is no mode specified, etc. In a typical main view dialog box, the designed resource file is as follows:
Resource dialog r_dlgapp_main_dialog
{
Flags = eeikdialogflagnodrag | eeikdialogflagnotitlebar |
Eeikdialogflagfillappclientrect | eeikdialogflagcbabuttons |
Eeikdialogflagmodeless;
Buttons = r_dlgapp_softkeys_options_home;
Pages = r_dlgapp_main_pages;
}
When constructing, first look:
Void cdlgappui: constructl ()
{
Baseconstructl ();
Iappview = new (eleave) cdlgappmainview;
Iappview-> executeld (r_dlgapp_main_dialog );
Addtostackl (iappview );
}
We must add controls to the Control Stack by ourselves, because the non-mode dialog box itself does not.
Let's look at the view structure. Each running application has a view of the current activity, the view structure applies to those views that are not released for external applications or those applications that can handle external application interruptions. A program using a view structure always has a view in the active State and others in the inactive state. When switching a view, the activation and inactive behaviors of one view and another view are generated, note that if you switch from an application and return to the program, no view activation and non-activation will be generated.
The Application User Interface creates and registers each view and determines whether to activate or deactivate it as a response to events from the view server. Note that when any view is activated, the corresponding memory may be cleared.
The current activation view can accept various events, which tell the application when to appear at the front-end and when to hide to the background. The corresponding view will accept foreground and background events.
The views of various applications are on the same layer, although the navigation between views can be arranged by hierarchy. Each view is like a small application user interface, which implements a large number of functions for the program to use. For example, you must provide an ID () function for the system to recognize. In addition, doactivatel (), dodeactivate (), handleforegroundeventl (), handlecommandl (), handlestatuspanesizechange (), and other functions are reloaded.
When processing the doactivatel () function, it is performed when the client requests to activate a view. One thing that must be considered is how to handle this function when the view is already active, in this case, some specific parameters are usually required.
Dodeactivate () is called only when the program exits, or when the view is switched. If no, this function does not exit abnormally, which is nice :)
Handleforegroundeventl () is called when the view is active. When the view is in the foreground, it receives the handleforegroundeventl (etrue) event and receives the handleforegroundeventl (efalse) event in the background. This function may be called many times when the view is active, because the program to which the view belongs is repeatedly switched on the backend and foreground. This function can be used to set focus or control screen updates.
Handlecommandl () calls this program when the View menu generates a command.
Handlestatuspanesizechange () This function is called when the client region size changes due to the Status Pane. This function is special.
The typical sequence of events received by the view during its activity is as follows:
Doactivatel ()
Handleforegroundeventl (etrue)
Handleforegroundeventl (efalse)
Dodeactivate ()
A view also requires resource files. If you need your own menu or CBA, you need to create such an avkon_view resource file, for example:
Resource avkon_view r_viewapp_view1
{
Hotkeys = r_viewapp_hotkeys;
Menubar = r_viewapp_view1_memubar;
CBA = r_avkon_softkeys_options_back;
}
Note that the view itself has no drawing capability and no interaction. They need to have the container classes inherited from mcoecontrolobserver and ccoecontrol to have such capabilities. Therefore, in the cakvview class (generally, their own views are derived from this class, such as cmyviewarchappview1) there will be an instance with a container.
Class cmyviewarchappview1: Public caknview
{
//...
PRIVATE:
Cmyviewarchappview1container * iview;
}
Here cmyviewarchappview1container is
Class cmyviewarchappview1container: Public ccoecontrol,
Mcoecontrolobserver
Local view switching, which is very common, mainly uses iavkonviewappui-> activatelocalviewl (tuid: UID (2 ));
UID of the switched View
Note that each view may have its own menu. to switch the view, first update the corresponding menu content of the View:
Ieikonenv-> appuifacloud ()-> menubar ()-> setmenutitleresourceid (r_my_view_arch_app_view2_menu );
// Switch the view only after this step.
If the doactivatel () function exits abnormally, the system will have its own recovery mechanism, that is, call dodeactivatel () to restore the previous view of the application. This makes it unnecessary for us to implement any processing mechanism in doactivatel.
If the application has multiple views or modes for processing different types of data on the top layer, we should discard the dialog box structure. The other two structures are better at communicating with the top layer, the top layer is the core engine.
If the program is to provide different views to external programs, you 'd better use the view structure. In this case, a display page of the program is used, it looks like running in an external process. In this case, the display page should be implemented in a DLL file that can be connected to the external file.
If you use the view structure, you must be able to handle unexpected activation caused by external application; otherwise, you should not use it. Use the other two methods instead.
If an external program needs to perform complex data interaction with the program, note that a customer/server system can work with any of the three structures.
Now let's talk about the main framework classes of Symbian:
It has four basic frameworks. Although it is not comparable to the MFC framework, it does have similarities.
Application, document, appui, View
The application is the startup object of the application, just like the cwinapp class of MFC. It defines the properties of the application, and this class also creates a document. The base class of this application class is caknapplication.
Document is used as a program to store data. An application must have an instance of document class, which may be the only requirement for loading Appui. The base class of this class is cakndocument, it is like the cdoument of MFC, which is used to process permanent storage in MFC :)
Appui is responsible for handling application-related events, such as options menu options and opening and closing of files. Note that it delegates graphic rendering and screen-based interaction operations to its own views and switches between views. The base class of Appui is caknappui or caknviewappui. I think this class is somewhat similar to cframewnd in MFC.
View is more complex. It is mainly responsible for displaying the data on the screen that can interact with users and giving feedback on user operations to Appui. As mentioned above, is used to process application-related events.
View can be inherited from ccoecontrol, cakndialog, or caknview. It can be seen that none of the three basic structure views are the main character. This is very important. The displayed task is handed over to it. Render manager is a traditional, dialog box, or view structure.
As we have mentioned earlier in Symbian, there are interfaces and engines. Previously we talked about interface-related, which engine is usually implemented in our own class libraries, it mainly reflects the functions of the application and processes its Algorithm The term "model/engine" is also used here.
For example, the framework creates an application, the application creates a document, the Appui is created in the document, and the Appui owns model/engine and view.