Dialogs are UI elements used by GUI applications.

Dialog terminology

Dialog terminology

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.


This API is valid for all platforms running on Symbian OS v9.1 or later.

Classification and release information

Dialogs API is an SDK API.

Related APIs
  • CEikDialog

API description

Dialogs 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

    • Creating dialog without menu

    • Creating dialog with menu

    • Launching the 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 structure

Many 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 .

Dialogs API

Dialogs API

Related APIs
  • CAknDialog
  • CEikDialog
Related APIs
  • CAknDialog
  • CEikDialog

Using Dialogs API

Two 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 resource

A 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 flags

The 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


CEikDialog::ExecuteLD() does not return until the dialog is dismissed.


The dialog does not grab the pointer, and it is not added to the control stack (so it cannot receive key presses).


The dialog has no title bar.


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.


The dialog is sized to fill the screen.


The dialog is sized to fill the client rectangle.


The dialog has CBA buttons.


Spacing around dialog components is minimized.


Do not use a backup window to minimize redrawing. By default, dialogs use screen backup to minimize redrawing. For more information, see RWindowBase::EnableBackup() .


The dialog framework calls CEikDialog::OkToExitL() when the Cancel button is activated (or its hotkey, Esc, is pressed).


The user cannot dismiss the dialog. This is often used for progress dialogs.


No border is drawn for this dialog, TGulBorder::ENone


Disable the dialog’s shadow, CEikonEnv::AddWindowShadow() .


Related to the internal method DoFadeBehindPopup() .


Used by EAknDialogMarkableList . DialogPageSelector forwards up/down events to its PageContainer .


The following flags are combined using | (binary or) into a single flag. ( EEikDialogFlagNoDrag | EEikDialogFlagNoTitleBar | EEikDialogFlagFillAppClientRect | EEikDialogFlagCbaButtons | EEikDialogFlagWait )


CAknDialog::SetEmphasis() called by the framework returns immediately, when that dialog is not constructed.


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


The dialog’s button panel is positioned below the dialog lines.


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.


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.


The dialog has no title bar.

Related APIs
  • CAknDialog::SetEmphasis()
  • CEikDialog::ExecuteLD()
  • CEikDialog::OkToExitL()
  • CEikonEnv::AddWindowShadow()
  • 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 resource

The 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 flags

Dialog items can have their own flags, as specified in Table 5.

Dialog item flags


If there is insufficient space on the dialog, the item has priority for using the available width.


Item height does not expand to fill the available space.


Item width does not expand to fill the available space.


If there is insufficient space for the item, the item is scaled to get an equal share of the available space.


Specifies that the line is specified indirectly through an LLINK.


The item is initially invisible, and requires a call from the client to make it visible.


A latent group line ( EEikDlgItemLatent ) follows.


No border is drawn for this item, TGulBorder::ENone .


The item does not take keyboard focus.


A separator is drawn after this line.


Provides a mask for DLG_LINE flags ( EEikDlgItemNoSeparator , EEikDlgItemSeparatorAfter ).


Item responds to the Enter key.


The item should be offered all hot key events.


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


Treat the line as a label (does not respond to input).


Not used.


If there is insufficient space on the dialog, the item has priority for using the available width.


Item height does not expand to fill the available space.


No separator is drawn between this line and the next.

Related APIs
  • 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 softkeys

The 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

Defining single-page dialog resource

The 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;
    items =
            type = EEikCtNumberEditor; 
            prompt = "Number1:";
            id = ESinglePageDlgC1Id;
            control = NUMBER_EDITOR { min=0; max=999; };
            trailer = "cm";
            type = EEikCtNumberEditor; 
            prompt = "Number2:";
            id = EsinglePageDlgC2Id;
            control = NUMBER_EDITOR { min=0; max=999; };
            trailer = "cm";
Related APIs
  • r_demo_singlepage_dialog

Defining multi-page dialog resource

Multi-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.

Multi-page dialog

Multi-page dialog

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 |
    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 =
            id = EAknExFormPageCtrlIdPage01;
            text = qtn_multipage_form_label_page1;
            form = r_multipage_form_text_field_form;
            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 =
            type = EEikCtEdwin;
            prompt = qtn_multipage_form_label_edwin;
            id = EAknExFormDlgCtrlIdEdwin11;
            itemflags = EEikDlgItemTakesEnterKey | 
            control = EDWIN
                flags = EEikEdwinNoHorizScrolling | 
                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
  • PAGE
  • r_multipage_form_pages

Creating and launching dialog

The 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












Creating dialog without menu

The following example code creates a standard CEikDialog .

               CEikDialog* dlg = new (ELeave) CEikDialog();
Related APIs
  • CEikDialog

Creating dialog with menu

The 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
  • CAknDialog

Launching the dialog

The 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 dialog

Below is an example custom dialog:

              class CMyDialog: public CAknDialog
public:     // construction
    static TInt RunDlgLD( TInt aResouceId );
private:    // construction
    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 function

If 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
  • PreLayoutDynInitL()

Checking exit condition

The 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
  • OkToExitL()

Adding custom control to dialog

Controls 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:

    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;

    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()
  • Draw()
  • MinimumSize()
  • SizeChanged()

Handling command

In 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()

        case EAknCmdExit:
        case EEikCmdExit:

            CAknDialog::ProcessCommandL( aCommandId );
Related APIs
  • OkToExitL()
  • ProcessCommandL()
  • TryExitL()

Handling key events

In 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;
        result = CAknDialog::OfferKeyEventL( aKeyEvent, aType );
    return result;

Error handling

Dialogs API uses standard Symbian platform error reporting mechanism and standard error codes.

Memory overhead

Memory consumption of dialogs depends on the contained controls.

Limitations of the API


Related APIs
  • CAknDialog
  • CEikDialog



Dialogs API abbreviations

API Application Programming Interface


Command Button Area


Graphical User Interface


Operating System


Software Development Kit


Dialogs API definitions

Softkey A command button mapped to a hard key on the device.


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