--- a/Symbian3/SDK/Source/GUID-A62E89DE-0762-5827-856D-F20EEF46EE4B-GENID-1-8-1-3-1-1-7-1-7-1-4-1.dita	Wed Mar 31 11:11:55 2010 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,12 +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-A62E89DE-0762-5827-856D-F20EEF46EE4B-GENID-1-8-1-3-1-1-7-1-7-1-4-1"><title>Simple controls and compound controls</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>In addition to being window-owning or non-window-owning, each control is either a simple control or a compound control. </p> <section><title>Simple controls</title> <p>A simple control, such as a label or an image, is one which contains no other controls. A simple control may be window-owning or non-window-owning. The majority of simple controls, in practice, are non-window-owning. </p> </section> <section id="GUID-A62E89DE-0762-5827-856D-F20EEF46EE4B-GENID-1-8-1-3-1-1-7-1-7-1-4-1-2-3"><title>Compound controls</title> <p>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. </p> <p>The controls contained by a compound control are its component controls. Components may also be window-owning or non-window-owning. The majority, in practice, are non-window-owning. </p> <p>The implementation of compound controls changed in version 9.1 of Symbian OS. The previous APIs and the old 'way of working' are still supported but do not support new automated features such as background drawing, font provision, layout managers and accumulated zoom. </p> <p>The new 'way of working' is currently used by UIQ v3. </p> <p>S60, MOAP and older versions of UIQ use the old scheme. </p> <p>Under the old (pre 9.1) scheme the way in which a compound control stored its component controls is not mandated by the framework. Controls derived from <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita"><apiname>CCoeControl</apiname></xref> are free to store their components as they see fit. They have to implement the virtual function <codeph>CCoeControl::CountComponentControls()</codeph> to return the number of components, and also to provide <codeph>CCoeControl::ComponentControl()</codeph> to return the <codeph>CCoeControl*</codeph> pointing to a particular component. This is very flexible but places a greater burden on application developers and means that it is impossible for tools or agents to make assumptions about the internal structure of controls. </p> <p>Under the new (9.1 and onwards) scheme <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita"><apiname>CCoeControl</apiname></xref> provides a storage mechanism and an API for adding, retrieving and removing components. Besides simplifying the API and making life easier for developers this ensures consistency which allows run-time agents, such as layout managers and skins managers, to act across all of the controls in the UI. The <codeph>CCoeControl::CountComponentControls()</codeph> and <codeph>CCoeControl::ComponentControl()</codeph> functions are now implemented by the base class. By default, <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita"><apiname>CCoeControl</apiname></xref> also now takes responsibility for deleting its lodgers. </p> <p>The new scheme provides two methods for identifying component controls - one to be used by the parent, which gives each sibling component a unique ID, and one which allows each control within a view to have a UniqueHandle. The latter is primarily to enable resource driven view construction but is also useful for automated testing. </p> <p>The control framework (both old and new) provides logic to handle redrawing and the distribution of pointer events to component controls. A compound control must handle distribution of key events to its components. Non-window owning lodger components should not overlap* and must be contained within the extent of the compound control. This does not pose a restriction for most UI elements, such as buttons and labels, as they never need to overlap and never need to be displayed outside their containers. </p> <p>Component controls may themselves be compound. There is no limit on the number of levels of compounding. </p> <p> </p> <p>*Overlapping controls may be used in conjunction with <xref href="GUID-48DD4B1F-E056-344F-9311-43D89F3817B8.dita"><apiname>MCoeControlHitTest</apiname></xref>. 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-AC723EE4-1482-59C5-9F13-CAE119C7800D-GENID-1-8-1-3-1-1-7-1-9-1-2-21">How to write controls</xref>  </p> </section> <section><title>See also</title> <p> <xref href="GUID-E244744F-4837-5B46-8E37-4666A28BF0B7-GENID-1-8-1-3-1-1-7-1-7-1-5-1.dita">Run-time control hierarchy</xref>  </p> <p> <xref href="GUID-B84FA223-3DFD-58C5-8CEF-C5AA73AA6290-GENID-1-8-1-3-1-1-7-1-9-1.dita">How to write controls</xref>  </p> </section> </conbody></concept>
\ No newline at end of file