--- a/Symbian3/SDK/Source/GUID-E244744F-4837-5B46-8E37-4666A28BF0B7-GENID-1-8-1-6-1-1-4-1-6-1-7-1-5-1.dita	Wed Mar 31 11:11:55 2010 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,14 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
-<!-- This component and the accompanying materials are made available under the terms of the License 
-"Eclipse Public License v1.0" which accompanies this distribution, 
-and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
-<!-- Initial Contributors:
-    Nokia Corporation - initial contribution.
-Contributors: 
--->
-<!DOCTYPE concept
-  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<concept xml:lang="en" id="GUID-E244744F-4837-5B46-8E37-4666A28BF0B7-GENID-1-8-1-6-1-1-4-1-6-1-7-1-5-1"><title>The run-time control hierarchy</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>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. </p> <fig id="GUID-C54A1D04-CA7D-5E3D-8FA0-327D511D5D45-GENID-1-8-1-6-1-1-4-1-6-1-7-1-5-1-2-2"><title>
-          The run-time control hierarchy 
-        </title> <image href="GUID-4303DBDB-3F67-54E6-AB24-5E1871053ED9_d0e51838_href.png" placement="inline"/></fig> <p>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. </p> <p>A window-owning component is confined to the nearest window-owning control above it in the hierarchy. </p> <p>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). </p> <ul><li id="GUID-1EDC9967-25E6-5CA4-9754-1304FFE8A4F0-GENID-1-8-1-6-1-1-4-1-6-1-7-1-5-1-2-6-1"><p>Application-initiated redrawing follows the control framework run-time hierarchy: controls are drawn by their parents regardless of whether they are window-owning or not. </p> </li> <li id="GUID-ED6464FC-485A-5E62-BBE6-D297A975BF71-GENID-1-8-1-6-1-1-4-1-6-1-7-1-5-1-2-6-2"><p>Window-Server-initiated redrawing, on the other hand, follows the Window Server hierarchy: parents do not draw their window-owning children. </p> </li> </ul> <p>A control's container or parent control may not be changed after it has been set. </p> <p>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. </p> <p>In UIQ v3 the parent pointer is enabled. In S60 and MOAP the parent pointer currently is not enabled. </p> <p>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 <xref href="GUID-B84FA223-3DFD-58C5-8CEF-C5AA73AA6290-GENID-1-8-1-3-1-1-7-1-9-1.dita#GUID-B84FA223-3DFD-58C5-8CEF-C5AA73AA6290-GENID-1-8-1-3-1-1-7-1-9-1/GUID-3F0E8223-2218-5C95-AFBC-D66AD1DB12A7-GENID-1-8-1-3-1-1-7-1-9-1-2-14">how to write a control</xref>). </p> <p>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. </p> <ul><li id="GUID-9AA456A8-EB70-562F-8303-EF825BBA48E9-GENID-1-8-1-6-1-1-4-1-6-1-7-1-5-1-2-12-1"><p>When a control is drawn it must have the correct Look and Feel: its colours, fonts, font style, size and shape must be correct. Controls use their parent's graphics contexts and text drawers. </p> </li> <li id="GUID-38B4FE1B-BEE7-53DE-A8C6-192D7BF9B1AA-GENID-1-8-1-6-1-1-4-1-6-1-7-1-5-1-2-12-2"><p>If a control (lodger or a parent) changes size, the controls around or within it might have to move or resize. From 9.1 the framework provides a layout manager interface (<xref href="GUID-A622B8C7-60F4-38E8-B102-14883BCBA249.dita"><apiname>MCoeLayoutManager</apiname></xref>). Controls use the run-time hierarchy to find the appropriate layout manager. </p> </li> <li id="GUID-9EE92BB4-AC03-55FF-96BE-402B19EEC8FA-GENID-1-8-1-6-1-1-4-1-6-1-7-1-5-1-2-12-3"><p>From 9.1 parent controls take responsibility for drawing behind their children. This allows flexibility with backgrounds, transparent controls and controls which appear non-rectangular. To enable this process to work with window-owning controls (necessary because the Window Server will not allow parent windows to draw behind child windows) a new interface, <xref href="GUID-88936D48-B801-3D9C-8A9D-3498807937CE.dita"><apiname>MCoeControlBackground</apiname></xref>, has been introduced. When a window owning control draws itself it first looks for an <xref href="GUID-88936D48-B801-3D9C-8A9D-3498807937CE.dita"><apiname>MCoeControlBackground</apiname></xref> in its chain of parents and calls <codeph>MCoeControlBackground::Draw()</codeph> before drawing itself. </p> </li> </ul> <p> </p> </conbody></concept>
\ No newline at end of file