<?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 id="GUID-3FE54688-2CDE-5359-9ABB-B83BFA025A81" xml:lang="en"><title>Window-owning
controls and non-window-owning controls</title><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>Controls are similar to windows in the Window Server in that they are both
bounded areas of the screen and both user interface elements. They are not
synonymous, however, as a control may take up the whole of a window’s area
or only part of it. For this reason controls are divided into two types: window-owning
controls and non-window-owning controls. </p>
<section id="GUID-A9A8EEB4-2E5D-4926-97C7-33A1A0CF67CB"><title>Window-owning controls</title> <p>A window-owning control
has the same size and position as a window in the Window Server. Window-owning
controls may overlap each other and may be moved around the screen within
the bounds of their parent window. Dialogs, menus, toolbars and <keyword>top-level
controls</keyword> are typically window-owning controls. </p> </section>
<section id="GUID-E0C33F8A-9A4A-4953-A57C-E96921290086"><title>Non-window-owning controls (lodger controls)</title> <p>The
majority of controls are non-window-owning. A non-window-owning control’s <keyword>extent</keyword> typically
covers only part of a window on the screen: usually it is one of a number
of controls within a larger <keyword>compound control</keyword> which acts
as a container. </p> <p>Examples of non-window-owning controls include command
buttons, text boxes and labels. </p> <p>Non-window-owning controls give greater
efficiency as they require fewer resources in the Window Server and fewer
process switches. They can also result in faster intialisation and redrawing
because a compound control and all its non-window-owning components can be
drawn with a single flush to the window server. </p> </section>
<section id="GUID-22B830AC-D43C-4FB6-9C5D-1F89AD65EF8F"><title>Associated windows</title> <p>All controls have an <keyword>associated
window</keyword>, whether they are window-owning or not. For a window-owning
control the associated window is the window it owns. For a non-window-owning
control the associated window is the window owned by the nearest window-owning
control above it in the control hierarchy. </p> </section>
<section id="GUID-C62985F2-84D3-44C5-BB1E-9576227FBC74"><title>See also</title> <ul>
<li><p><xref href="GUID-2C443E6F-BC3D-5252-8098-9F850AA88A35.dita">Window server</xref></p></li>
<li><p><xref href="GUID-E244744F-4837-5B46-8E37-4666A28BF0B7.dita">Run-time control
hierarchy</xref></p></li>
<li><p><xref href="GUID-B84FA223-3DFD-58C5-8CEF-C5AA73AA6290.dita">How to write
controls</xref></p></li>
</ul></section>
</conbody></concept>