Hello Stephen,
a touch interaction (once begun) remains associated to the original event handler. This so-called grab cycle ensures that the handler which has received a press event will not loose the control and also will receive a release event. See also Touch events and the grab cycle.
This grab cycle can be terminated prematurely and the interaction can be relayed to a new event handler. In the simplest case you configure the so-called RetargetCondition in the original handler to achieve this. See also Combine several Touch Handlers together. As soon as the specified condition is fulfilled, the handler will try to find another handler which is willing to take over the interaction. This technique is used often to implement complex UI with nested lists and widgets the user can scroll and interact with.
More low-level approach is the usage of the methods RetargetCursor() or DeflectCursor(). The idea: the code executed in context of the actually active handler invokes the method to 'relay' the actual interaction to other handler. This could be the handler found in other component, e.g. in the previously presented dialog. This requires the code to have access to he component and to its handler. It means to 'know' them. You will need to remember the presented dialog e.g. in a variable so that the code triggered by the original handler can see whether the variable is initialized and relay the interaction in such case.
For example, following could be the implementation of a slot method associated to the original handler. That means the code is executed in context of the original handler:
// Is there is a dialog presented, relay the interaction to its handler
if ( the_dialog )
GetRoot().DeflectCursor( the_dialog.SomeTouchHandler, <0,0>);
If you plan to use dialogs, please remind that the dialogs appear asynchronously. That mean, that the effect of PresentDialog() has a delay. Even if the_dialog from the code above exists already, it can eventually be not yet visible and not yet ready to handle touch events. If the dialog does not perform any animations, following could be sufficient. Now the code is executed when the dialog is already part of the view tree:
// Is there is a dialog presented and already visible, relay the interaction to its handler
if ( the_dialog && the_dialog.Owner )
GetRoot().DeflectCursor( the_dialog.SomeTouchHandler, <0,0>);
Well, so far technical backgrounds. I'm not sure whether it helps you further or not. From our experience, I would recommend other approach. Let the original handler handle the user interaction. That means, when the user taped with two fingers and dragged them, present the new dialog but let the original handler continue handling the events. Just limit to invoke a method in the presented dialog to inform it about the performed drag operation. The dialog can then update its state/position etc. For example:
// Is there is a dialog presented, then just inform it about the dragged finger
if ( the_dialog && the_dialog.Owner )
the_dialog.SomeUpdateMethod( TouchHandler.CurrentPos );
Best regards
Paul Banach
