By standard now, our window class will use the two-phase construction idiom. Note, although the SDK provides everything that is needed to use this idiom, it does not force the developer to use it, nor does it enforce the use of exceptions as the means of error handling.
Here's the C++ constructor of the class:
If the base class construction turns out to be a success, we set the title of the window, then specify 5x5 padding for the widget area. This padding doesn't mean that each widget placed on the window will be surrounded by 5 pixels of empty space. It simply means that there will be an inset of 5 pixels to the window bounds. We also set the background color to white.
If the demo application was already used once, the settings should contain the position of the window on screen. If this is the case, we read that position from the settings and move the window accordingly.
The instantiation of our console will be placed in the ConstructL() method of the window, as it can throw an exception:
If the cWindow class does not delete all its children views when it is destroyed, we would have had to add the destruction of iConsole in it. However since it does, the class destructor is empty.
Here is the method NewL() of the window class:
The method Ready() and CloseRequested() are implemented in our class and defined in cWindow. The first one is called after the window is displayed on screen. We will be using it to set the beat rate of the window, which our console widget needs for the active button animation:
The constant kBeatRate is defined as const tUint32 kBeatRate = 150 and is expressed in milliseconds.
When the user asks to close the window, the method CloseRequested() will be executed. If it returns true, the window will be closed, else it will remain open. This is the perfect time for us to save the current position of the window on screen, for future usage:
Here's the header and the C++ file of cDWindow.
We are now going to derive the application class to create and display the window. We will also be retrieving the application settings. Here's the application declaration from DApplication.h:
The method Ready() is called once the application starts to run. We will use this method to construct and display the window. First, let's see the class constructor:
The first argument of the base class constructor is the name of the application. This name will be used to identify the application if we wanted to send some scripting messages to it. We will come back to that later. The class cSettings from which we instantiate iSettings provides access to the application settings. If something is wrong with it, or if the object cannot be created, the data member iFault of the application will be set to something other than kErrNone.
If you recall the destructor of cDWindow, you may remember that we didn't delete the console widget in it, since the window took care of that. The application class, does not take care of deleting the window for us, so we will need to delete iWindow in it: