Series 60 uses notes to convey information to users about a current situation. In general, a note is displayed on screen for a couple of seconds, but it can be dismissed earlier by the user .

A number of predefined notes exist, which give the functionality and appearance required by most applications. These predefined notes range from confirming actions to providing warnings to a user and are outlined in Table 6-2.

Wrapped notes and global notes offer an easy way to display simple notification messages. (However, global notes should be used sparingly as they take system focus even when the application that called them is in the background.) Wait and Progress notes are more complex and require a little more work.

Example implementations of all these note types are featured in later sections of this chapter. The applications ConfirmationNote, WaitNote , and ProgressNote are used as the basis of the discussion that follows .

Bear in mind that notes should be used sparingly to achieve maximum effect in an application. This is particularly true of the more serious error notes and warning notes ”an information note should be used in preference to an error note unless something serious has happened . Please refer to the Series 60 UI style guide, provided with the SDK documentation, for further details.

Wrapped Notes

To standardize the notifications displayed by applications and to make life easier for developers, Series 60 offers wrapped notes . These are standard notes where you just need to supply the text you want to display. It is not necessary to specify a resource ”a wrapped note will already have a resource associated with it, and this will define the layout, particular image and tone sound for it to use. There are four different types of wrapped notes: Confirmation Note, Information Note, Warning Note and Error Note. Table 6-2 shows an example note of each type and describes the tone associated with each.

Table 6-2. Predefined Notes

Type of Note

Class Name





Informs that an action was successful (for example, a game saved successfully). A short, quiet tone may play when the note displays.



Informs that an error occurred which can be rectified, usually in response to user input (for example, entering a duplicate player name). A medium tone may play when the note displays.



Informs that a situation occurred that may require user intervention (for example, reaching the maximum number of saved games for an application). A long, loud tone plays when the note displays.



Informs that a serious situation occurred, which could cause considerable problems if the user does not intervene (for example, entering an incorrect PIN, causing a lock out). A long, distinctive tone plays when the note displays.


CAknWaitDialog /CAknWaitNoteWrapper

Informs a user that an event is occurring which may take some time, but gives no indication of the progress or length of the event. An animation shows while the event is occurring. Pressing the right soft key cancels the note and the processing. Otherwise , the wait note closes when the processing completes.



Informs a user that an event is occurring which may take some time. The progress or length of the event is indicated by means of a progress bar, which increments at regular intervals. Pressing the right soft key cancels the note and the processing. Otherwise, the progress note closes when the processing completes.



Displays even if the application launching the note is not currently displayed. You can use such notes to display information, warnings, confirmations , errors, information about the current battery state, and so on. A permanent note does not timeout or disappear when the user presses a key, and must be cancelled in code.



You can customize notes if required (for example, to display a different icon). Text can be either static (for example, "Saving Game") or variable (for example, "Delete saved game 3," where the number of games is determined at runtime). Note that the variable part may only be an integer. CAknNoteDialog does not derive from CAknDialog and so has no menu capabilities.

The application ConfirmationNote shows how to use a wrapped note. This particular example displays a confirmation note, but all wrapped notes are executed similarly. When Save Game is selected from the Options menu, the current game "saves," and, if successful, a note displays to confirm this, as shown in Figure 6-19. The code for "saving the game" is not actually implemented ”an empty method, SaveGame() is used to indicate where the saving would be performed.

Figure 6-19. Game saved confirmation note.

A wrapped note is initially created using the first-phase constructor. For a confirmation note, the class of interest is CAknConfirmationNote . Construction is then completed using ExecuteLD() , passing in a descriptor for the note to display. This function completes the second phase of construction, displays the note and destroys it on exit. In ConfirmationNote , the note is executed in the CConfirmationNoteAppUi::HandleCommandL() function:

 HBufC* noteText; noteText = StringLoader::LoadLC(R_SAVED_GAME_NOTE_TEXT); CAknConfirmationNote* note = new (ELeave) CAknConfirmationNote(); note->ExecuteLD(*noteText); CleanupStack::PopAndDestroy(noteText); 

The construction and execution of all standard wrapped notes follows this same pattern. The only thing that differs is the name of the class itself. This name can be CAknConfirmationNote , CAknInformationNote , CAknWarningNote or CAknErrorNote .

Customized Notes

If you need to deviate from the standard wrapped notes ”for example, to provide a custom bitmap or a different tone ”you can define your own resource for the note and execute this instead. In the ConfirmationNote example, when the application is started, a customized confirmation note is displayed to indicate how many saved games have been loaded, as shown in Figure 6-20.

Figure 6-20. Customized confirmation note.

Although this note appears similar to the wrapped note seen earlier, it has been customized to display a different bitmap icon ”as defined by the following resource:

 RESOURCE DIALOG r_confirmationnote_loaded_games_note    {    flags = EAknConfirmationNoteFlags;    items =       {       DLG_LINE          {          type = EAknCtNote;          id = EConfirmationNote;          control = AVKON_NOTE             {             layout = EGeneralLayout;             singular_label = LOADED_GAMES_SINGULAR_TEXT;             plural_label = LOADED_GAMES_PLURAL_TEXT;             imagefile = "z:\system\data\avkon.mbm";             imageid = EMbmAvkonQgn_indi_marked_add;             imagemask = EMbmAvkonQgn_indi_marked_add_mask;             };          }       };    } 

The resource uses standard flags , which determine to some extent the type of note that displays. The EAknConfirmationNoteFlags flag is used to indicate that it is a confirmation note.

By default, a confirmation note has no soft key labels, but it cancels if the user presses either key. To explicitly label the right soft key as Cancel you can specify the soft keys for the note to be R_AVKON_SOFTKEYS_CANCEL in the buttons field of the DIALOG resource.

The dialog should have a single line, which as usual has a type ( EAknCtNote) , an id , and a control (of type AVKON_NOTE) .

For the AVKON_NOTE control, the following need to be defined:

  • layout ” This determines the note's appearance. The general layout has been specified for the ConfirmationNote example, but other options can be found in avkon.hrh .

  • singular_label and plural_label ” These set different text to be displayed for singular and plural labels. In the ConfirmationNote example, the labels are set to " Loaded %d game " and " Loaded %d games ", respectively. The value for the " %d " is set when the note is constructed . Note that using the StringLoader class and the SetTextL() method can produce more flexible results at runtime.

  • imagefile, imageid and imagemask ” These determine what image the note will display. In the ConfirmationNote example, the standard confirmation note icon is not displayed. For simplicity, another image from avkon.mbm was chosen , but you can define your own image. The imagefile specifies the location of the . mbm file containing the image to be displayed. The imageid is the position of the image in that file, and the imagemask is the position of the image mask in the file.

Constructing and Executing a Customized Note

To create a customized note, derive the note dialog class from CAknNoteDialog . It should be constructed using standard dialog construction and execution methods . In the ConfirmationNote example, this is performed in the container's ConstructL() method.

[View full width]
[View full width]
void CConfirmationNoteContainer::ConstructL(const TRect& aRect) { CreateWindowL(); CAknNoteDialog* note = new (ELeave) CAknNoteDialog(CAknNoteDialog::EConfirmationTone, CAknNoteDialog::EShortTimeout); note->PrepareLC(R_CONFIRMATIONNOTE_LOADED_GAMES_NOTE); TInt numberOfLoadedGames = LoadGames(); note->SetTextPluralityL(numberOfLoadedGames > 1); note->SetTextNumberL(numberOfLoadedGames); note->RunLD(); SetRect(aRect); ActivateL(); }

The constructor requires arguments for the tone and timeout value. As the ConfirmationNote example customizes a confirmation note, it passes in EConfirmationTone for the tone and EShortTimeout for the timeout. This is essentially what the confirmation wrapper class does for you. The note can be executed by calling ExecuteLD() , passing in the DIALOG resource created in the previous step.

Alternatively, if it is required to call other methods before execution, you must call PrepareLC() first, then call any other methods, and then call RunLD() . In the ConfirmationNote example, the dynamic element of the message label must be set, so the PrepareLC() , RunLD() route was chosen. The dynamic text for the ConfirmationNote example relates to the number of games loaded. A dummy method, LoadGames() , has been implemented to determine this value. If more than one game has been loaded, SetTextPluralityL() is called, passing ETRue , and the plural_label will then be used. If only one game has been loaded, SetTextPluralityL () is called with EFalse and the singular_label used.

Wait Notes

A wait note is used to inform the user that processing is taking place ”no indication is given of the time needed to complete the processing. This subsection looks at the WaitNote example, which shows how to create a wait note. This involves defining the note in resource, constructing and executing a wait note wrapper object, and creating a MAknBackgroundProcess derived class.

In the WaitNote application, selecting Save Game from the Options menu causes a wait note to display while the game saves, as shown in Figure 6-21. If the user cancels the note, the application cancels the saving of the game. The methods for saving the game and canceling saving are not actually implemented ”the dummy methods, SaveGamePartToFile() , CompleteGameSave() , and CancelGameSave() are used to indicate where this functionality would be performed.

Figure 6-21. Wait note.

Defining a Wait Note in Resource

A wait note is defined in a resource structure using a DIALOG in a similar way to a customized note.

 RESOURCE DIALOG r_waitnote_saving_game_note    {    flags = EAknWaitNoteFlags;    items =       {       DLG_LINE          {          type = EAknCtNote;          id = EConfirmationNoteDlgCIdSavingNote;          control = AVKON_NOTE             {             layout = EWaitLayout;             singular_label = SAVING_GAME_TEXT;             imagefile = "z:\system\data\avkon.mbm";             imageid = EMbmAvkonQgn_note_progress;             imagemask = EMbmAvkonQgn_note_progress_mask;             animation = R_QGN_GRAF_WAIT_BAR_ANIM;             };          }       };    } 

Set the dialog flags to EAknWaitNoteFlags .

The AVKON_NOTE should have:

  • layout set to EWaitLayout .

  • animation field to animate the wait bar. Set this to R_QGN_GRAF_WAIT_BAR_ANIM to obtain the standard animation.

  • imagefile , imageid and imagemask appropriate for a wait note. This is set to standard wait note values in the WaitNote example.

Constructing and Executing a Wait Note Wrapper Object

Wait note wrappers are constructed and executed in a different way to other dialogs. A wait note wrapper is actually a wait note wrapped up in an Active Object, so it does not behave in the same way as other dialogs. The same functionality can be achieved using the CAknWaitDialog , but this involves writing an Active Object ( CActive -derived class) and is therefore slightly more complex. The progress note in the next subsection shows how this is done.

A wait note wrapper is constructed and executed using its NewL() and ExecuteL() methods. In the WaitNote example, this is performed in response to the user selecting Saved Game from the Options menu, in CWaitNoteContainer::SaveGameL() .

 void CWaitNoteContainer::SaveGameL()    {    CAknWaitNoteWrapper* waitNoteWrapper = CAknWaitNoteWrapper::NewL();    // reinterpret_cast is required as CAknWaitNoteWrapper inherits privately from CActive!       CleanupStack::PushL(reinterpret_cast<CBase*>(waitNoteWrapper));    if (!waitNoteWrapper->ExecuteL(R_WAITNOTE_SAVING_GAME_NOTE, *this))       {       CancelGameSave();       }    CleanupStack::PopAndDestroy(waitNoteWrapper);    } 

The ExecuteL() function must be supplied with a DIALOG resource and a reference to a MAknBackgroundProcess object (implementation of this mixin class is discussed in the next subsection). In the WaitNote example, the container class, CWaitNoteContainer , implements MAknBackgroundProcess , so a dereferenced this pointer is passed through. ExecuteL() blocks until the processing is complete, and a TBool is returned indicating whether the processing completed ( ETRue ) or the user cancelled the note ( EFalse ). In the WaitNote example, the game save is cancelled if the method returns EFalse .

Unlike other dialogs, wait notes do not delete when they finish executing; they must be deleted explicitly. In the WaitNote example, the note is a local variable, so deletion is achieved through the call to CleanupStack::PopAndDestroy() .

If the note wrapper is not member data of a class, use a reinterpret cast to cast it to a CBase pointer in order to place it onto the CleanupStack . It cannot be placed directly onto the CleanupStack , as it privately inherits from CActive , which means that it has no (implicit) public converter to CBase* !

Creating an MAknBackgroundProcess-Derived class

A class that implements MAknBackgroundProcess is required in order to be able to instantiate the wrapper. In the WaitNote example, the container class does this job.

 class CWaitNoteContainer : public CCoeControl, public MAknBackgroundProcess    { private: // from MAknBackgroundProcess    void DialogDismissedL(TInt /*aButtonId*/);    TBool IsProcessDone() const;    void ProcessFinished();    void StepL();    ... 

MAknBackgroundProcess encapsulates the processing that occurs while the wait note displays. In WaitNote , the processing performed is the saving of the game ”the wait note wrapper encapsulates an Active Object, which calls the methods in MAknBackgroundProcess as it runs.

The processing should occur in a number of small steps. In the WaitNote example, the saving of the game is split into steps, which execute in the SaveGamePartToFile() method (this is a dummy method and nothing is actually saved to a file). The number of steps completed so far is indicated by iStepsCompleted . Active Objects are covered in more detail in Chapter 3.

CAknWaitNoteWrapper is an Active Object, and so calling ExecuteL() results in a service request being made to the Active Scheduler. When the request has been serviced, MAknBackgroundProcess::IsProcessDone() is called to determine whether all of the steps of the processing have been carried out. If they have not, EFalse will be returned and MAknBackgroundProcess::StepL() will be called, causing the next step of the processing to be carried out.

If the processing is allowed to complete ”that is, the user does not cancel the dialog ”the framework calls MAknBackgroundProcess::ProcessFinished() and then MAknBackgroundProcess::DialogDismissedL() . If the user does end the processing, DialogDismissedL() is called first by the framework. It then calls IsProcessDone() to check whether the processing has finished, followed by ProcessFinished() .

The method to determine whether processing is complete is IsProcessDone() .

 TBool CWaitNoteContainer::IsProcessDone() const    {    return (iStepsCompleted == KNumberOfStepsToSaveGame);    } 

If the processing is complete, Etrue is returned, and EFalse if not. In the WaitNote example, this means checking that all the required steps in the procedure have been carried out, and if so, returning Etrue . In a real application, this would mean implementing some kind of state machine, or at the very least using a member flag to indicate when processing is complete.

The StepL() method is where small steps of the processing should be completed.

 void CWaitNoteContainer::StepL()    {    SaveGamePartToFile();    iStepsCompleted++;    } 

In the WaitNote example, the SaveGamePartToFile() dummy method simply wastes some time using an RTimer object.

The StepL() method executes synchronously. It should therefore process quickly ”otherwise it will not be possible to cancel the note. The thread will block, and there will be a large delay in displaying the note, as it does not display until one step completes.

Use the ProcessFinished() or the DialogDismissedL() methods to do any postprocessing work required, such as closing files, resetting state machines, and the like.

 void CWaitNoteContainer::ProcessFinished()    {    CompleteGameSave();    iStepsCompleted = 0;    } 

In the WaitNote example, the implementation of ProcessFinished() just calls a dummy method to complete the game save and to reset the steps completed counter.

Progress Notes

Progress Notes are similar to wait notes, but they give the user a visual indication of what portion of the processing is still left to do. In this subsection, the application ProgressNote is used to demonstrate the techniques you should use to create a progress note. The basic steps are as follows:

Declare the progress note.

Create the progress note for a variable-length process.

Execute the progress note.

Update the progress note as a process executes.

Handle user cancels and completion of the progress note.

In ProgressNote , selecting Save Game from the Options menu displays a progress note while the game saves, as shown in Figure 6-22. If the user cancels the note, the application cancels the game saving. The functions to save the game and cancel saving have not been fully implemented ”the dummy methods SaveGamePartToFile() , CompleteGameSave() , and CancelGameSave() are used to indicate where this functionality would be performed.

Figure 6-22. Progress note.

Declaring a Progress Note

A progress note contains a progress bar. At regular intervals during the execution of the process it is necessary to increment and redraw the progress bar. The process needs to run asynchronously in small steps, preferably using an Active Object. Otherwise, the thread will block and the note will not update or may not even display until the processing is complete.

An Active Object is created in the usual way by deriving from CActive . In ProgressNote , CProgressNoteGameSaverAO is declared as an Active Object:

 class CProgressNoteGameSaverAO : public CActive, MProgressDialogCallback    {    ... private: // from CActive    void RunL();    void DoCancel(); private: //data    CAknProgressDialog* iProgressDialog;    ... 

A progress note is a nonwaiting dialog. That is, while the dialog is executing, the application can continue processing in the background. This is essential if the note is to update correctly. A progress note should be declared as member data, and then deleted in the class destructor. If execution completes normally ”that is, no leave occurs ”the progress note deletes itself and sets the pointer to it to NULL . However, if a leave occurs during the background processing, the note has no knowledge of this and cannot delete itself. Therefore, its deletion must be handled in the destructor. (You will see how it is possible for the dialog to null the pointer to itself in the next step of the ProgressNote example.)

Creating a Progress Note for a Variable-Length Process

A progress note is constructed just before a long-running process is about to begin, usually within an Active Object. In ProgressNote , the note is constructed in CProgressNoteGameSaverAO::SaveGameL() .

[View full width]
[View full width]
void CProgressNoteGameSaverAO::SaveGameL() { iProgressDialog = new (ELeave) CAknProgressDialog(reinterpret_cast<CEikDialog**> (&iProgressDialog)); ...

There are two constructors that can be used to create a variable-length progress note. The one used here creates a progress note that will display only after 1.5 seconds of processing and will display for a minimum of 1.5 seconds. If the processing completes within the initial 1.5 seconds, the note will not be displayed. This stops the note from flashing on screen and then disappearing in the case of short processes. The other constructor has a TBool parameter, which can be set to ETRue to prevent this delay. Use this only if you are certain that processing will take at least 1.5 seconds.

Both constructors have a parameter referred to in the documentation as a self-pointer. It is actually the address of the member data pointer for the note, so in the ProgressNote example it is the address of iProgressDialog . The method expects a CEikDialog** , so a reinterpret cast is required, as shown in SaveGameL() . The note sets the self-pointer to NULL when it deletes itself. As discussed in the previous step, this is to allow the safe deletion of the note in the destructor if necessary, without any possibility of a double deletion occurring.

Executing a Progress Note

Once the progress note is constructed, it can be prepared and run. This is performed in CProgressNoteGameSaverAO::SaveGameL() :

 ... iProgressDialog->PrepareLC(R_PROGRESSNOTE_SAVING_GAME_NOTE); iProgressDialog->SetCallback(this); CEikProgressInfo* progressBar = iProgressDialog->GetProgressInfoL(); progressBar->SetFinalValue(KFinalValue); iProgressDialog->RunLD(); SaveGamePartToFile(); progressBar->IncrementAndDraw(KIncrement); SetActive(); } 

As methods will be called on the progress note, the dialog is prepared for use by calling PrepareLC() and passing through the resource. (The definition of the DIALOG resource, r_progressnote_saving_game_note , can be found in ProgressNote.rss . )

As with all dialogs, progress notes are, by default, nonwaiting. Nonwaiting progress notes do not return a value when they finish executing, so this cannot be used to determine whether the user cancelled the note or the process completed normally. Instead, a callback is set on the note by calling CAknProgressDialog::SetCallback() , passing in an MProgressDialogCallback object. DialogDismissedL() is called on the callback object when the dialog has been dismissed. The mechanics of this function is discussed in detail later ”see Completion of a Progress Note and User Cancellation .

As the progress bar will represent the proportion of the task completed, it is necessary to set the number of individual units for the bar. The progress bar, of type CEikProgressInfo , can be retrieved by calling GetProgressInfoL() on the dialog. A call to CEikProgressInfo::SetFinalValue() is used to set the number of units the bar represents. Note that, although GetProgressInfoL() returns a pointer to the progress bar, the application does not take ownership of it.

The note is instantiated using RunLD() ”this returns immediately, allowing processing to begin. The RunLD() method has a " D " suffix, which usually indicates that the object deletes itself just before the method returns. In common with other nonwaiting dialogs, however, the note does not delete when the RunLD() method returns. Instead it is deleted when ProcessFinishedL() is called, or, if the user dismisses the note, after a call to the DialogDismissedL() method (called by OkToExitL() ).

The processing in the ProgressNote example is performed in the SaveGamePartToFile() function. This encapsulates an asynchronous request, hence the call to SetActive() .

Updating a Progress Note as a Process Executes

It is necessary to update the progress bar at regular stages during the execution of the process and dismiss it when processing finishes. The RunL() of the Active Object is the natural place to do this.

 void CProgressNoteGameSaverAO::RunL()    {    if (!IsProcessDone())       {       SaveGamePartToFile();       iProgressDialog->GetProgressInfoL()->IncrementAndDraw(KIncrement);       SetActive();       }    else       {       iProgressDialog->ProcessFinishedL();       }    } 

The RunL() method should first check whether all processing is complete. In the ProgressNote example, the local method IsProcessDone() is used to determine this ”it simply checks that a counter has not reached its limit. If processing is complete, the progress note should be informed by calling its ProcessFinishedL() method. The note will then call the DialogDismissedL() method and delete itself, setting its self-pointer to null.

If processing is not yet complete, then the following steps should be continued until it is:

Perform a step in the processing. The ProgressNote example simulates saving the game in the SaveGamePartToFile() method ”this is the asynchronous request for the Active Object.

Update the progress bar accordingly , using the IncrementAndDraw() method. In the ProgressNote example, the steps are of even length, so the progress bar can be incremented by a constant value, KIncrement . If the process has uneven steps, you may use a variable for this. The progress bar, instead of being incremented and drawn, can be set and drawn using the SetAndDraw() method. This disregards any previous value for the progress bar and sets its position to that specified in the arguments to the method.

Set the Active Object to be active. This is so that RunL() is called again to complete the next step, if there is one. The progress note will dismiss automatically, once it has been incremented sufficiently that it has reached its final value. The final value should be selected and incremented with care, to ensure that it does not dismiss before the processing is complete.

Completion of a Progress Note and User Cancellation

MProgressDialogCallback::DialogDismissedL() is called when the progress dialog is dismissed. Perform any cleanup in this method ”in the case of a user cancellation ”or do further processing after a successful completion.

In the ProgressNote application, IsProcessDone() is called to determine whether or not the processing was complete when the dialog was dismissed. If it was not, then the user must have chosen to cancel the processing, so the saving of the game will be canceled .

 void CProgressNoteGameSaverAO::DialogDismissedL(TInt /*aButtonId*/)    {    if (!IsProcessDone())       {       CancelGameSave();       }    else       {       CompleteGameSave();       }    iStepsCompleted = 0;    } 

Fixed-Period Progress Notes

If the length of time a process will take is known, a progress dialog can be instantiated and its display can be updated automatically. Again, this is performed within an Active Object. However, the note object itself increments and redraws the progress bar automatically, so there is no need for this to be done in the code.

[View full width]
[View full width]
const TInt KFinalValue = 5; const TInt KInterval = 100; const TInt KIncrement = 1; SaveGamePartToFile(); SetActive(); iProgressDialog = new (ELeave) CAknProgressDialog(KFinalValue, KIncrement, KInterval, reinterpret_cast<CEikDialog**>(&iProgressDialog)); iProgressDialog->ExecuteLD(R_PROGRESSNOTE_SAVING_GAME_NOTE);

The following three parameters are required. They determine how the progress bar increments, and the length of the process:

  • Final Value ” As in the ProgressNote example, this determines the number of units in the progress bar.

  • Increment ” The number of units the progress will move when it is incremented.

  • Interval ” How often the progress bar increments in hundredths of a second.

For example, for a process that takes 5 seconds the bar could be 5 units long, with 1-unit increments, and increments occurring every second. The progress note would display for 5 seconds. The following formula can be used to calculate approximate values for an application: duration = interval * final value / increment .

You may need to experiment with the values to make a progress bar update smoothly and to give it the appearance of doing something all the time. An interval of less than 100 can cause the total time the note displays to increase dramatically from what might be expected. Dismissing the dialog as soon as the processing is finished is possible, but it might be confusing for the user if the progress bar does not reach its final value.

Global Notes

A global note dialog is displayed on screen even if the application that owns it is not in focus. The code used to display a global note is quite simple, but should be used sparingly. It does not require the definition of a note in a resource structure, although this can be done for a customized note.

Construction and execution of a global note is performed using the NewLC() and ShowNoteL() methods. A note type is supplied to the ShowNoteL() method, plus the text to be displayed. The aknnotifystd.h header file defines the possible note types in the TAknGlobalNoteType enumeration.

 HBufC* noteText; noteText = StringLoader::LoadLC(R_GLOBAL_NOTE_TEXT); CAknGlobalNote* globalNote = CAknGlobalNote::NewLC(); iNoteId = globalNote->ShowNoteL(EAknGlobalPermanentNote, *noteText); CleanupStack::PopAndDestroy(globalNote); CleanupStack::PopAndDestroy(noteText); 

All global notes have a CancelNoteL() method that can be called to dismiss them. This method requires the ID of the note to be cancelled ”the ID returned when calling the ShowNoteL() method. Permanent notes do not timeout and cannot be dismissed by the user, they must be cancelled programmatically using CancelNoteL() .

Global notes do not have menus or soft keys defined and so will lock the UI of a device until cancelled.

Developing Series 60 Applications. A Guide for Symbian OS C++ Developers
Developing Series 60 Applications: A Guide for Symbian OS C++ Developers: A Guide for Symbian OS C++ Developers
ISBN: 0321227220
EAN: 2147483647
Year: 2003
Pages: 139 © 2008-2017.
If you may any questions please contact us: