Symbian3/SDK/Source/GUID-D3F52BB9-7230-499C-9BB7-CFAEDBA8F48B.dita
author Dominic Pinkman <dominic.pinkman@nokia.com>
Fri, 11 Jun 2010 12:39:03 +0100
changeset 8 ae94777fff8f
parent 7 51a74ef9ed63
child 13 48780e181b38
permissions -rw-r--r--
Week 23 contribution of SDK documentation content. See release notes for details. Fixes bugs Bug 2714, Bug 462.

<?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-D3F52BB9-7230-499C-9BB7-CFAEDBA8F48B" xml:lang="en"><title>Managing
feedback areas</title><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>Usually control areas (and hence feedback areas) should not overlap. However,
in some cases you may have to define a priority for the feedback areas. </p>
<p>Consider, for example, situations where a compound control has a simple
control inside its own area as illustrated in the figure below.</p>
<fig id="GUID-C70125A6-393A-428D-A22B-7F6EEC72FAAF">
<title>Tactile feedback area priorities</title>
<image href="GUID-5BD8EE4B-3149-4331-91E0-7813DF4994E1_d0e74056_href.png" scale="70" placement="inline"/>
</fig>
<p>In both situations, the compound control wants to give one type of feedback,
but there should be a different type of feedback (or no feedback at all) for
the simple control. Both controls can register themselves to area registry,
but the problem is making sure that simple control has a higher priority than
the compound control (in the API implementation hit tests are only run as
long as one control with matching area and pointer event type is found).</p>
<p>You can solve this in two ways:<ol>
<li id="GUID-7AE53987-EF45-4222-8D34-D48413091BC8">By adding the simple control
to area registry after compound control (the last added area always has the
highest priority inside its window).</li>
<li id="GUID-128E8207-1B69-4FC5-9E4B-A42A259C60E5">By using the <xref href="jar:GUID-759FBC7F-5384-4487-8457-A8D4B76F6AA6.jar!/html/classMTouchFeedback.html#a3fe25a09d2df942b13f626b627cb9e3" format="application/java-archive"><codeph>MoveFeedbackAreaToFirstPriority</codeph></xref> function for moving
the simple control to first priority.</li>
</ol></p>
<p>In many cases the first option is most natural choice, but you can also
use the second option in case the situation changes after the areas have been
already added to the area registry.</p>
<note><p>The priority order will only remain as long as the next area is added
to the registry, that is, moving some area to first priority will only keep
it as the top priority area as long as the next area is added to the registry.
(Registry entries of one window are kept in a stack, and new areas are always
added on top.)</p></note>
</conbody></concept>