diff -r 51a74ef9ed63 -r ae94777fff8f Symbian3/SDK/Source/GUID-D3F52BB9-7230-499C-9BB7-CFAEDBA8F48B.dita --- 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 @@ - - - - - -Managing -feedback areas -

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.

-

Consider, for example, situations where a compound control has a simple -control inside its own area as illustrated in the figure below.

- -Tactile feedback area priorities - - -

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).

-

You can solve this in two ways:

    -
  1. By adding the simple control -to area registry after compound control (the last added area always has the -highest priority inside its window).
    2. -
  2. By using the MoveFeedbackAreaToFirstPriority function for moving -the simple control to first priority.
    3. -

-

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.

-

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.)

 + + + + + +Managing +feedback areas +

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.

+

Consider, for example, situations where a compound control has a simple +control inside its own area as illustrated in the figure below.

+ +Tactile feedback area priorities + + +

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).

+

You can solve this in two ways:

    +
  1. By adding the simple control +to area registry after compound control (the last added area always has the +highest priority inside its window).
    2. +
  2. By using the MoveFeedbackAreaToFirstPriority function for moving +the simple control to first priority.
    3. +

+

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.

+

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.)

 \ No newline at end of file