Symbian
Symbian Developer Library

SYMBIAN OS V9.4

Feedback

[Index] [Previous] [Next]


The run-time control hierarchy

At run-time all controls in an application are related to each other in a tree hierarchy. The top-level window-owning controls are owned by the AppUi. This is similar to the hierarchy of windows that exists in the Window Server which has a group window for each application at the root. It is important to understand the relationships between window-owning and non-window owning controls. The diagram below attempts to illustrate these.

The run-time control hierarchy


The run-time control hierarchy

A non-window-owning control is confined to the extent of its parent if the parent is window-owning, and must be confined to the extent of its parent if the parent is non-window-owning.

A window-owning component is confined to the nearest window-owning control above it in the hierarchy.

Screen drawing may be initiated by either the application (because it's running and it has changed its display) or by the Window Server (because something else has updated the screen and the application is visible).

A control's container or parent control may not be changed after it has been set.

The run time hierarchy of controls has been enhanced for version 9.1 of the Symbian OS. The distinction between the 'parent-child' relationship from the Window Server and the 'container-component' relationship from the control framework may be simplified with the addition of a parent pointer to CCoeControl.

In UIQ v3 the parent pointer is enabled. In S60 and MOAP the parent pointer currently is not enabled.

The addition of the parent pointer allows the framework to navigate the control hierarchy upwards as well as downwards. When enabled, the parent pointer is set automatically (see how to write a control).

The run-time hierarchy is particularly significant when laying out and when refreshing the screen. Here are a few examples of how the framework uses the run-time hierarchy.

[Top]


See also

Window server.