<?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>

</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>