Symbian
Symbian Developer Library

SYMBIAN OS V9.4

Feedback

[Index] [Previous] [Next]


UI Control Framework Overview

[Top]


Architectural relationships

The control framework provides an abstract middle layer between the low-level windowing functionality, provided by the Window Server, and concrete user interface classes provided by Uikon and UI variant-specific libraries.

Application developers use the API directly to create their own controls and indirectly through derived classes provided by Uikon and UI variant libraries.

Cone architectural relationships


Cone architectural relationships

[Top]


Description


Controls

A control is a rectangular area of a window that may respond to user input. Controls have a number of properties that determine their behaviour and their relationships to other controls and windows.

A control is represented by the class CCoeControl.

A simple control is one which contains no other controls.

A container control is one which contains one or more controls. A container control is also referred to as a compound control. The contained controls may themselves be container controls. When a control is contained in a container control it is called a component control. A component control is always redrawn when its container control is redrawn.

The following diagram shows simple controls in orange and container controls in grey.

Simple and compound controls


Simple and compound controls

Controls and Windows

A window may be considered as a transparent layer. Windows are managed by the Window Server and described elsewhere. A control provides a means of access to a window - it can be drawn onto the window and can receive input.

Each window has a one-to-one relationship with a single control that covers it precisely. This control is referred to as a window-owning control. A window-owning control shares the behaviour of its window, in particular the parent-child window relationships which govern the window's position and overlapping behaviour.

A non-window-owning control typically covers only part of a window. It cannot be moved around on the screen independently of its window, cannot draw outside its window and is always a component control.

You might think of a window-owning control as a piece of glass and a non-window-owning control as a sticker on a window-owning control.


Application User Interface (AppUi) framework

The application user interface framework provides support for the distribution of key events to an application's controls. It maintains a control stack to which an application must add all the top-level container controls that it wishes to handle key events, setting a priority for each. When a key event occurs, the framework offers it to each control on the stack in priority order until it is consumed.

The application user interface framework is provided by the base class CCoeAppUi. Uikon and UI variants specialise CCoeAppUi further. Applications derive from the variant AppUi.

CCoeAppUi provides a simplified interface to the View Server which enables seemless switching between different views across various applications.


Control Environment (CoeEnv)

The Control Environment simplifies the interface to the Window Server and provides an environment for creating controls. It is a single instance (a singleton) of the class CCoeEnv which encapsulates an active scheduler and active objects for communicating with the window server. CCoeEnv is created automatically by the framework and a pointer stored in Thread Local Storage (TLS). It is available through CCoeControl::CoeEnv(), CCoeAppUi::CoeEnv() and through its own static function, CCoeEnv::Static(), which is less efficient.

The control environment also provides simplified access to drawing functions, fonts, and resource files which are used by most applications.

[Top]


See also

Uikon Overview

View Server Overview

Window Server

Asynchronous Programming (active scheduler & active objects)