Chapter 1

Instead of calling CreateWindowL() to create a window of the right size, I call
SetContainerWindowL() to register myself as a lodger of a control on an existing
window.
11.5.3 Compound Controls
There needs to be some structure in laying out lodger controls such as those in the
Battleships Start first game dialog, or indeed in the Battleships app view. That discipline is
obtained by using compound controls: a control is compound if it has one or more
component controls in addition to itself.
� A component control is contained entirely within the area of its owning control.
� All components of a control must have nonoverlapping rectangles.
� A component control does not have to be a lodger, it can also be window-owning. In
the majority of cases, however, a component control is a lodger.
To indicate ownership of component controls to CONE's framework, a compound control
must implement two virtual functions from CCoeControl:
� CountComponentControls() indicates how many components a control has – by
default, it has zero, but you can override this.
� ComponentControl() returns the nth component, with n from zero to the count of
components minus one. By default, this function panics (because it should never get
called at all if there are zero components). If you override
CountComponentControls(), you should also override this function to return a
component for each possible value of n.
Here is a generic example implementation of these functions. Most Symbian OS applications
use enums for their controls like:
enum
{
EMyFirstControl,
EMySecondControl,
EAmountOfControls
}
This enables you to simply return EAmountOfControls in the
CountComponentControls. This ensures that you do not forget to change your return
value when you add or remove controls over time:
TInt anyExampleAppView::CountComponentControls() const
{
return EAmountOfControls;
}
CCoeControl* anyExampleAppView::ComponentControl(TInt aIndex) const
{
switch (aIndex)
{
case 0: return EMyFirstControl;
case 1: return EMySecondControl;