Chapter 1

private to the app UI, so they were not given their own header.
The C++ constructor takes whatever parameter is necessary to connect the dialog to the
outside world – in this case, my app UI, since it's this dialog's job to set its iFileName and
iText members.
class CExampleWriteFileDialog : public CEikDialog
{
public:
CExampleWriteFileDialog(CExampleAppUi* aAppUi);
private:
// From CEikDialog
void PreLayoutDynInitL(); // Initialization
TBool OkToExitL(TInt aKeycode); // Termination
private:
CExampleAppUi* iAppUi;
};
Note
On reflection, this isn't actually a very good encapsulation of the interface: I
should really have passed references to the iFileName and iText
members to make it clear that the dialog is intended to alter them and
nothing else.
Initialization is performed by PreLayoutDynInitL().The 'prelayout' part of the name
means that the data you put into the dialog here will influence its layout – dialogs are laid out
automatically to incorporate the optimum size of controls for the initialization data supplied.
Here's PreLayoutDynInitL():
void CExampleWriteFileDialog::PreLayoutDynInitL()
{
CEikFileNameEditor* fnamed=STATIC_CAST(CEikFileNameEditor*,
Control
(EExampleControlIdFileName));
fnamed->SetTextL(iAppUi->iFileName);
CEikEdwin* edwin=STATIC_CAST(CEikEdwin*, Control
(EExampleControlIdText));
edwin->SetTextL(iAppUi->iText);
}
This simply sets the edit windows to the existing values in iFile-Name and iText.
Controls are identified by their ID, as specified in the id= line in the resource file definition.
Control() returns a CCoeControl* type and this must be cast to the actual control type
that it represents.