|
1 <?xml version="1.0" encoding="utf-8"?> |
|
2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> |
|
3 <!-- This component and the accompanying materials are made available under the terms of the License |
|
4 "Eclipse Public License v1.0" which accompanies this distribution, |
|
5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> |
|
6 <!-- Initial Contributors: |
|
7 Nokia Corporation - initial contribution. |
|
8 Contributors: |
|
9 --> |
|
10 <!DOCTYPE concept |
|
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
|
12 <concept id="GUID-D3F52BB9-7230-499C-9BB7-CFAEDBA8F48B" xml:lang="en"><title>Managing |
|
13 feedback areas</title><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
14 <p>Usually control areas (and hence feedback areas) should not overlap. However, |
|
15 in some cases you may have to define a priority for the feedback areas. </p> |
|
16 <p>Consider, for example, situations where a compound control has a simple |
|
17 control inside its own area as illustrated in the figure below.</p> |
|
18 <fig id="GUID-C70125A6-393A-428D-A22B-7F6EEC72FAAF"> |
|
19 <title>Tactile feedback area priorities</title> |
|
20 <image href="GUID-5BD8EE4B-3149-4331-91E0-7813DF4994E1_d0e79176_href.png" scale="70" placement="inline"/> |
|
21 </fig> |
|
22 <p>In both situations, the compound control wants to give one type of feedback, |
|
23 but there should be a different type of feedback (or no feedback at all) for |
|
24 the simple control. Both controls can register themselves to area registry, |
|
25 but the problem is making sure that simple control has a higher priority than |
|
26 the compound control (in the API implementation hit tests are only run as |
|
27 long as one control with matching area and pointer event type is found).</p> |
|
28 <p>You can solve this in two ways:<ol> |
|
29 <li id="GUID-7AE53987-EF45-4222-8D34-D48413091BC8">By adding the simple control |
|
30 to area registry after compound control (the last added area always has the |
|
31 highest priority inside its window).</li> |
|
32 <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 |
|
33 the simple control to first priority.</li> |
|
34 </ol></p> |
|
35 <p>In many cases the first option is most natural choice, but you can also |
|
36 use the second option in case the situation changes after the areas have been |
|
37 already added to the area registry.</p> |
|
38 <note><p>The priority order will only remain as long as the next area is added |
|
39 to the registry, that is, moving some area to first priority will only keep |
|
40 it as the top priority area as long as the next area is added to the registry. |
|
41 (Registry entries of one window are kept in a stack, and new areas are always |
|
42 added on top.)</p></note> |
|
43 </conbody></concept> |