diff -r 000000000000 -r 89d6a7a84779 Symbian3/SDK/Source/GUID-37E8A48E-09B8-5958-9263-B33EDAE3F7C6.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-37E8A48E-09B8-5958-9263-B33EDAE3F7C6.dita Thu Jan 21 18:18:20 2010 +0000 @@ -0,0 +1,75 @@ + + + + + +UI +Control Framework Overview +
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 + +
+
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 + +

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 behavior +of its window, in particular the parent-child window relationships which govern +the window's position and overlapping behavior.

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 seamless 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.

+
See also

Uikon +Overview

View +Server Overview

Window +Server

Asynchronous +Programming (active scheduler & active objects)

+
\ No newline at end of file