--- a/Symbian3/SDK/Source/GUID-D3F52BB9-7230-499C-9BB7-CFAEDBA8F48B.dita	Wed Mar 31 11:11:55 2010 +0100
+++ b/Symbian3/SDK/Source/GUID-D3F52BB9-7230-499C-9BB7-CFAEDBA8F48B.dita	Fri Jun 11 12:39:03 2010 +0100
@@ -1,43 +1,43 @@
-<?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_d0e79176_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>
+<?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>
\ No newline at end of file