|
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-27897E0D-D9D6-4007-A45E-62C366F1267C" xml:lang="en"><title>Using |
|
13 direct feedback</title><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
14 <p>Direct feedback means that the application triggers feedback itself based |
|
15 on received pointer events. This approach is in general necessary in three |
|
16 cases:<ol> |
|
17 <li id="GUID-23A79B78-9228-4FD9-ACF9-8031E09A036B">The triggering of feedback |
|
18 depends on the state of the control (or application) in such a way that the |
|
19 area registry cannot be used. For example: feedback is triggered from each |
|
20 new character when the user selects text with the stylus.</li> |
|
21 <li id="GUID-85A0716A-15ED-4E02-8E9D-57D2280E00F4">Feedback area is non-rectangular |
|
22 and thus area registry cannot be used. For example: the user taps a tab of |
|
23 a non-focused view in a view-based application.</li> |
|
24 <li id="GUID-5296912E-A665-45E5-A7A5-CD323C449C42">Feedback is triggered from |
|
25 pointer repeat events.</li> |
|
26 </ol></p> |
|
27 <note><p>In the first two cases the feedback must be generated on the pointer |
|
28 down event, even though the related action itself would be done only on the |
|
29 pointer up event.</p></note> |
|
30 <p>In a lot of cases, you may want to use both <xref href="GUID-10A03A8E-E967-4F9C-B911-2F06031C6ADC.dita">area |
|
31 registry based feedback</xref> and direct feedback in your application. In |
|
32 this case you must ensure these two do not overlap, so that direct feedback |
|
33 would be generated for some pointer events, which have already triggered feedback |
|
34 from the area registry.</p> |
|
35 <p>Use the <codeph>InstantFeedback</codeph> function to generate direct feedback. |
|
36 This always causes a synchronous client-server transaction immediately. (If |
|
37 tactile feedback is not supported in the device, the API implementation ignores |
|
38 the function call.)</p> |
|
39 <codeblock xml:space="preserve">void CMyTactileEnabledControl::HandlePointerEventL( |
|
40 const TPointerEvent& aPointerEvent ) |
|
41 { |
|
42 TBool stateChanged; |
|
43 |
|
44 // (your code here) |
|
45 |
|
46 if(aPointerEvent.iType == TPointerEvent::EDrag && stateChanged) |
|
47 { |
|
48 // Produce sensitive feedback when dragging causes a state |
|
49 // change (this kind of feedback triggering is not possible |
|
50 // by using area registry). |
|
51 MTouchFeedback* feedback = MTouchFeedback::Instance(); |
|
52 if ( feedback ) |
|
53 { |
|
54 feedback->InstantFeedback( ETouchFeedbackSensitive ); |
|
55 } |
|
56 } |
|
57 } |
|
58 </codeblock> |
|
59 <p>Also notice that there are two overloads of the <codeph>InstantFeedback</codeph> function: |
|
60 The first one only takes the logical feedback type as parameter, and can be |
|
61 used for generating feedback at any time, even when no UI controls are involved |
|
62 (for e.g. if the AppUi class wants to generate feedback). The second overload |
|
63 takes a <codeph>CCoeControl</codeph> pointer as parameter, and it does nothing |
|
64 in case feedback is disabled for the given control.</p> |
|
65 <p>The latter overload is recommended to be used from UI controls, because |
|
66 that gives the owner of the control a possibility to disable both area registry |
|
67 based and direct feedback if needed.</p> |
|
68 </conbody></concept> |