Simple controls and compound controls

In addition to being window-owning or non-window-owning, each control is either a simple control or a compound control.

A simple control is one which contains no other controls. Examples are command buttons and edit windows. A simple control may be window-owning or non-window-owning, but the majority of simple controls, in practice, are non-window-owning.

A compound control is one which contains one or more simple or compound controls. Compound controls are also known as container controls, and may be window-owning or non-window-owning.

The controls contained by a compound control are its component controls. Components may also be window-owning or non-window-owning, but the majority, in practice, are non-window-owning.

A compound control must override the function CCoeControl::CountComponentControls() to return the number of components, and must also provide CCoeControl::ComponentControl() to return the CCoeControl* pointing to a particular component. The control framework does not dictate how the components are stored within a compound control, nor how these two functions should be implemented. A generalised container might use an array for storage, and use the array’s count and access functions to implement the assessor functions. A specific control with known components might use member data to point to each control, a hard-coded count, and a switch statement to return components.

The control environment provides logic to handle redrawing and distribution of pointer events to its components. A compound control must handle distribution of key events to its components. Lodger components must not overlap, and must be contained within the extent of the compound control. This does not pose a restriction for most UI elements, however, such as buttons and labels, as they never need to overlap, and never need to be displayed outside their containers.

Component controls may themselves be compound. There is no limit on the number of levels of compounding.