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.
Figure: 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).
MTouchFeedback::MoveFeedbackAreaToFirstPriority
function for moving the simple control to first priority.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.
Note: 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.)