Dialogs API Specification
Changes in Dialogs API documentation
Changes in Dialogs API
PurposeDialogs are UI elements used by GUI applications. As shown in Figure 1, a dialog consists of a title, zero or more pages
consisting of a sequence of lines, and a row of one or more softkeys (CBA). The lines can only be arranged vertically, allowing for simpler programming,
a small application footprint, and a high likelihood of dialogs that are easy
for novice users to use. Each line consists of a label and a control for displaying
and entering data. The controls are: a choice list, a set of option buttons,
a check box, and input fields. Most dialogs have one page of controls. Multi-page tabs only appear in multi-page dialogs. They are used to access
separate dialog pages. When a lot of controls are put together on a single
dialog, a multi-page dialog (or occasionally a scrolling dialog) is invariably
used to fit all the controls neatly on devices’ small screens. There is a
difference between multi-page tabs with dialog architecture and multi-views
with view architecture. In views, the view state and data need to be saved
between the switch, and each view can be activated from outside by a view-switch
mechanism, whereas in multi-page dialogs data is saved when the dialog is
closed (after memory footprint) and it is not possible to reach individual
dialog tabs from outside the dialog. For typical dialog uses, a large collection of ready-made
dialog classes are provided.
-
Queries are small dialogs which are used for getting user input or selection.
See
Queries API Specification for more information.
-
Notifiers are used to display global dialogs. Notifiers are typically
used by components which have no UI context (for example, engine components).
See
Notifiers API Specification for more information.
-
Notes are small dialogs which show information, warning and error messages
to the user. See
Notes API Specification for more
information.
-
Forms are used to display and/or edit logically related data (for example,
settings). See
Form API Specification for more
information.
This document describes how to implement and use dialogs. For further information see API documentation for
CEikDialog in Symbian
OS v9.1 API Reference Guide for more information.
ConstraintsThis API is valid for all platforms running on Symbian OS v9.1 or later.
Classification and release informationDialogs API is an SDK API.
Related APIs
API descriptionDialogs API allows creating and using application-specific dialogs. Dialogs use the dialog resource, defined in the application resource file
(RSS). The runtime representations of dialogs are instances of the
CEikDialog and CAknDialog classes,
or any custom class deriving from the above. Derivation is used to add custom
functionality, controls or behavior to standard dialogs.
Use cases
-
Defining the resource
-
Defining the dialog resource
-
Defining the dialog line resource
-
Defining the softkeys
-
Defining single-page dialog resource
-
Defining multi-page dialog resource
-
Creating and launching dialog
-
Accessing control in dialog
-
Implementing custom dialog
-
Providing the factory function
-
Initializing controls
-
Checking the exit condition
-
Adding custom control to dialog
-
Handling commands
-
Handling key events
API class structureMany methods of
CEikDialog can be overridden to provide
custom behavior. If standard behavior and built-in components are sufficient, CEikDialog or CAknDialog can
be used directly.
CAknDialog adds Options menu handling to CEikDialog .
Related APIs
Related APIs
Using Dialogs APITwo steps are necessary to use dialogs:
-
Defining the dialog resource (
RESOURCE DIALOG ) in the
application resource file.
-
Instantiating the dialog class and launching the dialog. Existing classes
CEikDialog and CAknDialog can
be used. Custom dialogs can also be developed by deriving from these base
classes. Most methods of dialogs base classes are virtual.
Optionally, individual dialog lines and controls can be accessed and manipulated.
This enables modifying the dialog contents runtime.
Defining the resource
Defining the dialog resourceA
DIALOG resource encapsulates the structure of a dialog.
The developers need to define a dialog using the DIALOG resource.
Its STRUCT is defined in the eikon.rh file with the
following members: STRUCT DIALOG { LONG flags=0; LTEXT title=""; LLINK pages=0; LLINK buttons=0; STRUCT items[]; LLINK form=0; }
Dialog resource structure
|
|
LONG flags = 0;
|
Optional bitmask of flags governing attributes of the dialog. Defaults
to 0.
|
LTEXT title = "";
|
The title of the dialog, displayed at the top. Not really used in the
S60 on Symbian platform because most of the dialogs are full screen dialogs. — The status
pane would give information related to the dialog content.
|
LLINK pages = 0;
|
A resource defining the pages in a multi-page dialog. Do not specify
this if you only want a single-page dialog.
|
LLINK buttons = 0;
|
A resource defining the buttons to use in the dialog. The default is
no buttons.
|
STRUCT Items[];
|
A comma-separated list of dialog lines.
|
LLINK form = 0;
|
A reference to the FORM structure used in single-page forms. Can be
used to specify the style of the form.
Forms are documented in
Form API Specification .
|
Dialog flagsThe dialog types are defined by the flags parameter in the
DIALOG structure.
These are defined in the eikon.hrh and avkon.hrh files. The
basic dialog flags are defined by EEikDialogFlagXxx in the eikon.hrh file,
but some of them are not used. Note: Symbian OS versions older than v9.1 specify
the dialog flags in the
uikon.hrh file. Typical dialogs specify
EEikDialogFlagWait ; other flags
control keypad input flow, whether there is a title, and several others, as
shown in Table 2.
Dialog resource flags
|
|
EEikDialogFlagWait
|
CEikDialog::ExecuteLD() does not return until the
dialog is dismissed.
|
EEikDialogFlagModeless
|
The dialog does not grab the pointer, and it is not added to the control
stack (so it cannot receive key presses).
|
EEikDialogFlagNoTitleBar
|
The dialog has no title bar.
|
EEikDialogFlagAllKeysToButtons
|
This flag must be set for dialogs that use unmodified keys (that is,
keys which are not used in combination with Shift, Ctrl, or Fn). For example,
it would typically be set for a dialog that contains "Yes" and "No" buttons,
which are activated by an unmodified "Y" or "N" key press.
|
EEikDialogFlagFillScreen
|
The dialog is sized to fill the screen.
|
EEikDialogFlagFillAppClientRect
|
The dialog is sized to fill the client rectangle.
|
EEikDialogFlagCbaButtons
|
The dialog has CBA buttons.
|
EEikDialogFlagDensePacking
|
Spacing around dialog components is minimized.
|
EEikDialogFlagNoBackup
|
Do not use a backup window to minimize redrawing. By default, dialogs
use screen backup to minimize redrawing. For more information, see
RWindowBase::EnableBackup() .
|
EEikDialogFlagNotifyEsc
|
The dialog framework calls
CEikDialog::OkToExitL() when
the Cancel button is activated (or its hotkey, Esc, is pressed).
|
EEikDialogFlagNoUserExit
|
The user cannot dismiss the dialog. This is often used for progress
dialogs.
|
EEikDialogFlagNoBorder
|
No border is drawn for this dialog,
TGulBorder::ENone
|
EEikDialogFlagNoShadow
|
Disable the dialog’s shadow,
CEikonEnv::AddWindowShadow() .
|
EEikDialogFlagNoBackgroundFade
|
Related to the internal method
DoFadeBehindPopup() .
|
EEikDialogFlagDontEatUpDownEvents
|
Used by
EAknDialogMarkableList . DialogPageSelector forwards
up/down events to its PageContainer .
|
EAknDialogGenericFullScreen
|
The following flags are combined using | (binary or) into a single
flag. (
EEikDialogFlagNoDrag | EEikDialogFlagNoTitleBar | EEikDialogFlagFillAppClientRect | EEikDialogFlagCbaButtons | EEikDialogFlagWait )
|
EAknDialogFlagNotConstructed
|
CAknDialog::SetEmphasis() called by the framework
returns immediately, when that dialog is not constructed.
|
EAknDialogFlagDialogDeleted
|
CAknDialog::SetEmphasis() called by the framework
returns immediately, when that dialog is deleted already.
|
Note that for compatibility reasons some flags have been maintained in
the S60 on Symbian OS, but none of these are in use anymore in the S60 on Symbian OS.
These removed flags are listed in Table 3.
Removed dialog resource flags
|
|
EEikDialogFlagButtonsBelow
|
The dialog’s button panel is positioned below the dialog lines.
|
EEikDialogFlagButtonsRight
|
Not in S60 on Symbian OS. The dialog’s button panel is positioned to
the right of the dialog lines, with the buttons arranged vertically.
|
EEikDialogFlagNoDrag
|
Removed because no pointing device is defined in the current UI
versions. The dialog cannot be moved around the screen by dragging it with
the pointing device.
|
EEikDialogFlagNoTitleBar
|
The dialog has no title bar.
|
Related APIs
CAknDialog::SetEmphasis() CEikDialog::ExecuteLD() CEikDialog::OkToExitL() CEikonEnv::AddWindowShadow() DIALOG DialogPageSelector DoFadeBehindPopup() EAknDialogFlagDialogDeleted EAknDialogFlagNotConstructed EAknDialogGenericFullScreen EAknDialogMarkableList EEikDialogFlagAllKeysToButtons EEikDialogFlagButtonsBelow EEikDialogFlagButtonsRight EEikDialogFlagCbaButtons EEikDialogFlagDensePacking EEikDialogFlagDontEatUpDownEvents EEikDialogFlagFillAppClientRect EEikDialogFlagFillScreen EEikDialogFlagModeless EEikDialogFlagNoBackgroundFade EEikDialogFlagNoBackup EEikDialogFlagNoBorder EEikDialogFlagNoDrag EEikDialogFlagNoShadow EEikDialogFlagNoTitleBar EEikDialogFlagNoUserExit EEikDialogFlagNotifyEsc EEikDialogFlagWait EEikDialogFlagXxx PageContainer RWindowBase::EnableBackup() TGulBorder::ENone
Related APIs
Defining the dialog line resourceThe dialog line structure contained in dialogs is defined in the
eikon.rh file. STRUCT DLG_LINE { WORD type; LTEXT prompt; WORD id=0; LONG itemflags=0; STRUCT control; LTEXT trailer=""; LTEXT bmpfile = "" ; WORD bmpid = 0xffff ; WORD bmpmask ; LTEXT tooltip = "" ; }
Dialog line resource struct
Member |
Description |
WORD type;
|
The control factory identifier for a control. This may be a custom
control, or one of the stock control classes. The dialog object must be able
to understand the value of this WORD — unrecognized controls cause the dialog
to panic. Stock controls are identified by
EEikCt... and EAknCt... values
(defined in eikon.hrh and avkon.hrh, respectively). Dialogs
using custom controls must use custom type value and override the virtual CEikDialog::CreateCustomControlL() function
to create the custom control.
|
LTEXT prompt;
|
The text that appears in front of the control in this dialog line.
|
WORD id = 0;
|
The control ID. This can be used in the C++ source to refer to the
control in this dialog line. The ID must be defined in a HRH file. Default
value: 0
|
LONG itemflags = 0;
|
Item flags. Default value: 0 — no flags set.
|
STRUCT control;
|
Resource defining this control. This is the resource for a custom control
or one of the stock control classes. Target type: Varies according to the
value of the type member.
|
LTEXT trailer = "";
|
The text that appears after the control in this dialog line. Default
value: No trailer text.
|
LTEXT bmpfile = "" ;
|
Specifies the bitmap file name.
|
WORD bmpid = 0xffff ;
|
Icon image ID, which is the enumeration of an icon image. Default value: 0xffff
|
WORD bmpmask ;
|
Specifies the icon mask ID.
|
LTEXT tooltip = "" ;
|
Help text for the form line.
|
Dialog line flagsDialog items can have their own flags, as specified in Table 5.
Dialog item flags
|
|
EEikDlgItemCtlGetsWidthFirst
|
If there is insufficient space on the dialog, the item has priority
for using the available width.
|
EEikDlgItemCtlMinHeightOrLess
|
Item height does not expand to fill the available space.
|
EEikDlgItemCtlMinWidthOrLess
|
Item width does not expand to fill the available space.
|
EEikDlgItemCtlSharesWidth
|
If there is insufficient space for the item, the item is scaled to
get an equal share of the available space.
|
EEikDlgItemIndirect
|
Specifies that the line is specified indirectly through an LLINK.
|
EEikDlgItemLatent
|
The item is initially invisible, and requires a call from the client
to make it visible.
|
EEikDlgItemLglf
|
A latent group line (
EEikDlgItemLatent ) follows.
|
EEikDlgItemNoBorder
|
No border is drawn for this item,
TGulBorder::ENone .
|
EEikDlgItemNonFocusing
|
The item does not take keyboard focus.
|
EEikDlgItemSeparatorAfter
|
A separator is drawn after this line.
|
EEikDlgItemSeparatorMask
|
Provides a mask for
DLG_LINE flags (EEikDlgItemNoSeparator , EEikDlgItemSeparatorAfter ).
|
EEikDlgItemTakesEnterKey
|
Item responds to the Enter key.
|
EEikDlgItemOfferAllHotKeys
|
The item should be offered all hot key events.
|
EEikDlgItemTrailerAfterEar
|
The item specifies some text in a trailer field to place after the
input area ear.
|
The flags listed in Table 6 exist only for compatibility reasons.
Dialog item flags not in use
|
|
EEikDlgItemAsLabel
|
Treat the line as a label (does not respond to input).
|
EEikDlgItemColumnEnd
|
Not used.
|
EEikDlgItemCtlGetsWidthFirst
|
If there is insufficient space on the dialog, the item has priority
for using the available width.
|
EEikDlgItemCtlMinSizeOrLess
|
Item height does not expand to fill the available space.
|
EEikDlgItemNoSeparator
|
No separator is drawn between this line and the next.
|
Related APIs
DLG_LINE EEikDlgItemAsLabel EEikDlgItemColumnEnd EEikDlgItemCtlGetsWidthFirst EEikDlgItemCtlMinHeightOrLess EEikDlgItemCtlMinSizeOrLess EEikDlgItemCtlMinWidthOrLess EEikDlgItemCtlSharesWidth EEikDlgItemIndirect EEikDlgItemLatent EEikDlgItemLglf EEikDlgItemNoBorder EEikDlgItemNoSeparator EEikDlgItemNonFocusing EEikDlgItemOfferAllHotKeys EEikDlgItemSeparatorAfter EEikDlgItemSeparatorMask EEikDlgItemTakesEnterKey EEikDlgItemTrailerAfterEar TGulBorder::ENone
Related APIs
CEikDialog::CreateCustomControlL() EAknCt... EEikCt...
Defining the softkeysThe softkeys in dialogs (buttons field of the
DIALOG resource)
are defined by a CBA resource. Avkon provides predefined softkeys. The list
of predefined softkeys (R_AVKON_SOFTKEYS_XXX ) is in the avkon.rsg file.
If these predefined softkeys do not suffice, a new CBA resource can be defined.
Refer to Buttons API Specification for details.
Related APIs
DIALOG R_AVKON_SOFTKEYS_XXX
Defining single-page dialog resourceThe dialog resource is defined in the application resource file (RSS file).
The following code describes a single-page dialog resource called
r_demo_singlepage_dialog . RESOURCE DIALOG r_demo_singlepage_dialog { flags = EEikDialogFlagNoDrag | EEikDialogFlagFillAppClientRect | EEikDialogFlagCbaButtons | EEikDialogFlagWait; buttons = R_AVKON_SOFTKEYS_OK_CANCEL; items = { DLG_LINE { type = EEikCtNumberEditor; prompt = "Number1:"; id = ESinglePageDlgC1Id; control = NUMBER_EDITOR { min=0; max=999; }; trailer = "cm"; }, DLG_LINE { type = EEikCtNumberEditor; prompt = "Number2:"; id = EsinglePageDlgC2Id; control = NUMBER_EDITOR { min=0; max=999; }; trailer = "cm"; } }; }
Related APIs
Defining multi-page dialog resourceMulti-page dialogs also use the
DIALOG resource, but there
are some differences compared to single-page dialogs. Multi-page dialogs define
a list of pages instead of items in single-page dialogs. The softkeys defined
in the resource are generic to the entire dialog - not to each page. Below is an example of a multi-page dialog and its resource definition. This dialog has multiple pages. In the main resource, the only different thing compared to the single-page
resource is that the multi-page resource definition includes a pages field
with the name of another resource. RESOURCE DIALOG r_multipage_form { flags = EEikDialogFlagNoDrag | EEikDialogFlagFillAppClientRect | EEikDialogFlagNoTitleBar | EEikDialogFlagNoBorder | EEikDialogFlagCbaButtons; buttons = R_AVKON_SOFTKEYS_OPTIONS_BACK; pages = r_multipage_form_pages; }
The pages resource (
r_multipage_form_pages ) is an array
resource that consists of PAGE items that contain the text
on the tab and lines defined in other resources. RESOURCE ARRAY r_multipage_form_pages { items = { PAGE { id = EAknExFormPageCtrlIdPage01; text = qtn_multipage_form_label_page1; form = r_multipage_form_text_field_form; }, PAGE { id = EAknExFormPageCtrlIdPage02; text = qtn_multipage_form_label_page2; form = r_aknexform_text_number_field_form; }, ...
}; }
Every page resource is an array resource that consists of
DLG_LINE items.
The following shows the resource definition for the first page: RESOURCE FORM r_multipage_form_text_field_form { flags = EEikFormUseDoubleSpacedFormat; items = { DLG_LINE { type = EEikCtEdwin; prompt = qtn_multipage_form_label_edwin; id = EAknExFormDlgCtrlIdEdwin11; itemflags = EEikDlgItemTakesEnterKey | EEikDlgItemOfferAllHotKeys; control = EDWIN { flags = EEikEdwinNoHorizScrolling | EEikEdwinResizable; width = AKNEXFORM_EDWIN_WIDTH; lines = AKNEXFORM_EDWIN_LINES; maxlength = EAknExFormEdwinMaxLength; // added to limit expanding in forms. // If you want full screen use 5 here max_view_height_in_lines = 5; // if you have the line above, you must have this. // It's calculable from LAF base_line_delta = 21;
}; tooltip = qtn_multipage_hint_text_edwin; }, }; }
Related APIs
DIALOG DLG_LINE PAGE r_multipage_form_pages
Creating and launching dialogThe following table shows the sequence of method calls used to create,
initialize and run dialogs, see sub-chapters for examples. Only the most significant
methods are shown.
CMyDialog is included to represent the
methods typically provided by CAknDialog or CEikDialog -derived
classes.
Creating and launching dialogs
|
|
|
|
1
|
new
|
|
NewL
|
RunDlgLD
|
2
|
|
|
ConstructL
|
3
|
PrepareLC
|
ExecuteLD
|
|
|
4
|
RunLD
|
|
|
Creating dialog without menuThe following example code creates a standard
CEikDialog . CEikDialog* dlg = new (ELeave) CEikDialog();
Related APIs
Creating dialog with menuThe following example code creates a standard
CAknDialog and
constructs it with the specified menu resource (RESOURCE MENU_BAR ): CAknDialog* dlg = new (ELeave) CAknDialog(); CleanupStack::PushL( dlg ); dlg->ConstructL( R_DEMO_MENU ); CleanupStack::Pop( dlg );
Related APIs
Launching the dialogThe following code snippet launches the dialog using the specified resource
(
RESOURCE DIALOG ): dlg->ExecuteLD( R_DEMO_SINGLEPAGE_DIALOG );
Alternatively,
PrepareLC() and RunLD() can
be called: dlg->PrepareLC( R_DEMO_SINGLEPAGE_DIALOG ); // pushes dlg on the cleanup stack //... // Dynamic initialization of dialog, e.g. adding / removing dialog lines. // The dialog is on the stack. Mind the cleanup stack balance. //... dlg->RunLD(); // pops, runs and deletes the dialog
Derived classes may provide other factory functions (
NewL() , RunDlgLD() )
for convenience.
Related APIs
NewL() PrepareLC() RunDlgLD() RunLD()
Related APIs
CAknDialog CEikDialog CMyDialog ConstructL ExecuteLD NewL PrepareLC RunDlgLD RunLD
Implementing custom dialogBelow is an example custom dialog: class CMyDialog: public CAknDialog { public: // construction static TInt RunDlgLD( TInt aResouceId ); private: // construction CMyDialog(); virtual ~CMyDialog(); private: // from CAknDialog void PreLayoutDynInitL(); // initialize controls TBool OkToExitL( TInt aButtonId ); // exit condition SEikControlInfo CreateCustomControlL( TInt aControlType ); void ProcessCommandL( TInt aCommandId ); TKeyResponse OfferKeyEventL ( const TKeyEvent& aKeyEvent, TEventCode aType ); };
Providing the factory functionIf there is a derived class from
CAknDialog, a static
function RunDlgLD() may be implemented. In this function
instantiate an instance of the dialog and launch it with the appropriate resource. ExecuteLD has
the “LD” postfix. “L” means that this function may leave and “D” means it
destructs itself. The dialog should not be placed on the cleanup stack when ExecuteLD() is
called. ExecuteLD() guarantees that if it leaves, the dialog
will be deleted. TInt CMyDialog::RunDlgLD() { CMyDialog* dlg = new (ELeave) CMyDialog(); return dlg->ExecuteLD( R_DEMO_SINGLEPAGE_DIALOG ); }
Related APIs
CAknDialog, ExecuteLD ExecuteLD() RunDlgLD()
Initializing controls
PreLayoutDynInitL() is called by the dialog framework
before the dialog is sized and laid out. It may be overloaded to initialize
the control values that should influence sizing and layout. The default implementation
is empty. The following example code initializes the values of the two number editors: void CMyDialog::PreLayoutDynInitL() { // Get the Number1 editor control. CEikNumberEditor* editor1 = (CEikNumberEditor*) Control( ESinglePageDlgC1Id ); // Set the value to the Number1 editor. editor1->SetNumber( 100 ); // Get the Number2 editor control. CEikNumberEditor* editor2 = (CEikNumberEditor*) Control( ESinglePageDlgC2Id ); // Set the value to the Number2 editor. editor2->SetNumber( 200 ); }
Related APIs
Checking exit conditionThe following example code checks the validity of the values in the two
editor controls, if the dialog is accepted. If the values are not valid, the
dialog cannot be dismissed.
OkToExitL() can be the place
to handle button presses and commands. TBool CMyDialog::OkToExitL( TInt aButtonId ) { if ( EAknSoftkeyOk == aButtonId ) { // Dialog accepted, check the exit condition. // Get the Number1 editor control. CEikNumberEditor* editor1 = (CEikNumberEditor*) Control( ESingleDlgId ); // Get the Number2 editor control. CEikNumberEditor* editor2 = (CEikNumberEditor*) Control( ESingleDlg2Id ); // Check the validity of the values in the two editors. if ( editor1->Number() > editor2->Number() ) { // Exit condition failed. CAknErrorNote* note = new (ELeave) CAknErrorNote; note->ExecuteLD( _L("Number1 should be less than number2") ); return EFalse; } } return ETrue; }
Related APIs
Adding custom control to dialogControls in the dialog lines are created by the dialog framework. Creation
is based on the control type, specified in the
DLG_LINE resource.
Built-in control types are recognized by the framework. Custom controls types
must be recognized, and the appropriate custom control created in the CAknDialog -derived
custom dialog class. The following resource snippet defines a custom control type: DLG_LINE { type = EMyControl; id = EMyControlId; control = ..... }
The framework calls
CreateCustomControlL() to create the
custom control. CreateCustomControlL() should only create,
but not construct the created control. SEikControlInfo CMyDialog::CreateCustomControlL( TInt aControlType ) { SEikControlInfo controlInfo; ontrolInfo.iControl = NULL; controlInfo.iTrailerTextId = 0; controlInfo.iFlags = 0; switch ( aControlType ) { case EMyControl: controlInfo.iControl = new (ELeave) CMyControl; break;
default: break; } return controlInfo; }
The framework constructs the created control by calling
ConstructFromResourceL() . void CMyControl::ConstructFromResourceL( TResourceReader& aReader ) { // Construct the custom control from its resource. ... }
The custom control also needs a few other methods so it can be laid out
and drawn. For example, custom controls usually implement
MinimumSize() , SizeChanged() and Draw() methods. Details of creating a CCoeControl -based custom
control can be found in document Core UI API Specification .
Related APIs
CAknDialog CCoeControl ConstructFromResourceL() CreateCustomControlL() DLG_LINE Draw() MinimumSize() SizeChanged()
Handling commandIn the example below,
ProcessCommandL() responds to custom
and system commands. For the custom command,
TryExitL() is used which results
in a call to OkToExitL() . void CMyDialog::ProcessCommandL( TInt aCommandId ) { switch( aCommandId ) { case EMyCommand: { TryExitL( aCommandId ); // to OkToExitL() break; }
case EAknCmdExit: case EEikCmdExit: { ((CAknAppUi*)iEikonEnv->EikAppUi())->RunAppShutter(); break; }
default: { CAknDialog::ProcessCommandL( aCommandId ); } } }
Related APIs
OkToExitL() ProcessCommandL() TryExitL()
Handling key eventsIn the example below, a short press of the Selection key invokes a command. TKeyResponse CMyDialog::OfferKeyEventL ( const TKeyEvent& aKeyEvent, TEventCode aType ) { TKeyResponse result = EKeyWasNotConsumed; if ( ( aKeyEvent.iCode == EKeyOK || aKeyEvent.iCode == EKeyEnter ) && ( !(aKeyEvent.iModifiers & EModifierShift) ) ) { // Short press of selection key. ProcessCommandL( EMyCommand ); result = EKeyWasConsumed; } else { result = CAknDialog::OfferKeyEventL( aKeyEvent, aType ); } return result; }
Error handlingDialogs API uses standard Symbian platform error reporting mechanism and standard
error codes.
Memory overheadMemory consumption of dialogs depends on the contained controls.
Limitations of the APINone.
Related APIs
Glossary
Abbreviations
Dialogs API abbreviations
API |
Application Programming Interface |
CBA
|
Command Button Area
|
GUI
|
Graphical User Interface
|
OS
|
Operating System
|
SDK
|
Software Development Kit
|
Definitions
Dialogs API definitions
Softkey |
A command button mapped to a hard key on the device. |
References
Dialogs API references
Queries API Specification |
|
Notifiers API Specification
|
|
Notes API Specification
|
|
Form API Specification
|
|
Symbian OS v9.1 API Reference Guide
|
|
Buttons API Specification
|
|
Core UI API Specification
|
|
Copyright ©2010 Nokia Corporation and/or its subsidiary(-ies). All rights reserved. License: EPL
|