2 finger SlideTouchHandler intervene with SimpleTouchHandler

Question

Like the this project:   https://ask.embedded-wizard.de/9206/a-specific-gui-use-case

      At my project have 2 page: MainPage and DoubleFingerSlidePage.  MainPage will been default show when screen power ON, DoubleFingerSlidePage have 2 list that been control by 2 finger slide. When double finger slide at MainPage, EW will PresentDialog the DoubleFingerSlidePage

      MainPage is been divided to left area and right area,   if SlideTouchHandler.HittingPos at left area,  DoubleFingerSlidePage will show List1. if SlideTouchHandler.HittingPos at right area,  DoubleFingerSlidePage will show List2.

      I have many widgets such as buttons and sliders( use SimpleTouchHandler ) integrated into the MainDialog. So if two fingers touch the screen one after another, it will often come to the case that the first finger touches a widget, and the second touches elsewhere, which may be MainPage or another widget. In this case, recognition of 2 finger slide is also required.

       To overcome the difficulty,  I introduced a signal counting the finger number on the screen from the touch driver. My idea was to have the event that the finger number increases from 1 to 2  trigger Presenting the Dialog.

       For this way, when two finger touch at MainPage,  the DoubleFingerSlidePage will been PresenDialog Immediately. But if One of the two finger touch a widget, the widget function will been trigger before PresenDialog DoubleFingerSlidePage.  The widget function been trigger isn't we want to see.

       How to Avoid The widget function been trigger?

 

Answer 1

To Avoid The widget function been trigger, I set all the SimpleTouchHandler property LimitToFinger = 0. When the screen check more than 1 finger touch, forbid the SimpleTouchHandler trigger it's function.

We release this test fucntion to our customer , our customer find a new problem:

1. When one finger touch at MainPage,  other widget can't use at the same time

Answer 2

Hello ke007,

I have many widgets such as buttons and sliders( use SimpleTouchHandler ) integrated into the MainDialog. So if two fingers touch the screen one after another, it will often come to the case that the first finger touches a widget, and the second touches elsewhere, which may be MainPage or another widget. In this case, recognition of 2 finger slide is also required.

...

The widget function been trigger isn't we want to see.

Have you tested out the example I have prepared for you in the thread grab cycle and touch influence with another touch. It demonstrates how this is done.

To Avoid The widget function been trigger, I set all the SimpleTouchHandler property LimitToFinger = 0. When the screen check more than 1 finger touch, forbid the SimpleTouchHandler trigger it's function.

This will have the effect of the handler reacting only on the first finger (finger with number 0).

When one finger touch at MainPage,  other widget can't use at the same time

I'm not sure what behavior is your customer expecting. But from your description it seems to be contradictory. You can processes either two fingers as a composed 2-finger gesture or you process the touches as individual interactions. The UI can't deduce your intention what to do when the user touches the screen with two fingers.

Best regards

Paul Banach

Comments

Is it a problem related to the hardware, touch driver, EW software, some misunderstanding, misconfiguration, .. ?

So i creat a demonstrating. For the simple demonstrating the interval is not happen, but on Washing Maschine example WashingMachine_change is happen.

I think for this test, we can focus on the EW software, the Washing Maschine example run normal before add 2-finger-slide present DialogPanel function, this is the only change at the example project. 

I have try to reproduction the interval problem on a sample demonstrate, but unlucky it's failed.  Maybe the interval problem just happen on complex project, at the same time my project also a complex project.

On the Washing Maschine example, I use the simplest way and least change to reproduction the interval problem, i have pay more time on this problem and try too many way to resolve this problem or makesure the reasons. It's very lucky to reproduction  on a example，i need your help!!!

 

---

Hello ke007,

i need your help!!!

How am I supposed to help you if you leave my questions unanswered and ignore my suggestions?

Maybe the interval problem just happen on complex project, at the same time my project also a complex project.

As mentioned in my answer above, the Washing Maschine is a complex example. It consists of several touch handlers stacked one above another. Additionally the handlers enable/disable other handlers during interactions. Adding new handlers to this application may produce results which are unexpected at first glance.

Is there a specific reason you're focusing on this example?

Please try to reproduce the issue using a simple application with similar functionality to your product.

Best regards

Paul Banach

---

Another attempt but I have no idea if it will help you as I still don't understand the problem you are struggling with.

As you remember, I have mentioned a possibility to provide you a patch for version 12 or 13 to fix an error we have detected some time ago. You are working with version 11.

With following modification in the file Core.ewu in version 11 you could add a part of the patch. Search the file for the same lines and replace the numbers. Left is the old, right the new version:

---

Hello Paul:

    Thank you for your help.

     I have try to follow your suggestions, but i can't reproduce the issue using a simple application. 

     when two finger touch at MainPage,  the DoubleFingerSlidePage will been PresenDialog Immediately. But if One of the two finger touch a widget, the widget function will been trigger before PresenDialog DoubleFingerSlidePage

     My project have more Widgets and the problem is easily happen when 2-finger-slide touch on the SipmleTouchHandler which control List or ValueBar.  This is the reason i use the Washing Maschine example.  

---

Hello ke007,

I was able to reproduce your application case. When analyzing the behavior note following two aspects:

1. When you present a dialog via PresentDialog(), the corresponding dialog appears with a small delay of at least one screen update. This delay may become longer if the dialog is presented with an animation. This is expected behavior.

2. When you present the dialog inside a component, widgets existing inside this component continue reacting to user inputs. This is an expected behavior too (for details see Take a closer look at the Dialog functionality).

Now let us analyze the application case:

3. Let's assume there is a component containing a Simple Touch Handler configured to react on 2-finger taps.

4. Furthermore let's assume the Simple Touch Handler is configured to redirect the touch events to other handler when the user performed a wipe gesture.

5. Finally let's assume behind the Simple Touch Handler is found a widget e.g. Push Button.

6. Now the user touches the screen with two fingers.

7. The Simple Touch Handler responds to this event. A signal is sent to a slot method associated to its OnPress property.

8. In the slot method you present a dialog.

9. The dialog is presented in context of the component containing the Simple Touch Handler (it was the case in your version of Washing Maschine).

10. The dialog appears after a short delay (see 1 above)

11. Now the user drags the fingers.

12. The Simple Touch Handler detects this gestures and asks which GUI component is willing to take over the interaction.

13. Since the dialog is already visible (note 10), the touch handler existing in the dialog is able to take over the interaction.

This was the good scenario with a delay between the 2-finger tap and the finger movement large enough to present the dialog. Now let focus on a first bad scenario:

3-9. are the same as above.

14. Still before the dialog appeared the user dragged the finger.

15. The Simple Touch Handler detects this gestures and asks which GUI component is willing to take over the interaction.

16. The dialog is not yet visible. It can't take over the interaction. This is because of the aspect 1 above.

17. Therefore the widget in the background takes over.

18. Your widget is activated.

A second bad scenario:

3-9. are the same as above.

19. The dialog appears after a short delay (see 1 above)

20. Now the user drags the fingers.

21. The screen position where the user touched does not lie inside the Touch Handler in the dialog.

22. The Touch Handler in the dialog thus can't take over the interaction.

23. Therefore the widget in the background takes over. This is true even if the dialog is already presented (visible). This is because of aspect 2 above.

24. Your widget is activated.

Now please open my example I have prepared for you some weeks ago. This example is implemented to correctly handle the aspects 1 and 2:

25. The first important detail is, the component containing the Simple Touch Handler intended to detect the 2-finger gestures and present the DoubleFinger dialog is also a dialog. This Basic dialog is presented at the startup time of the application. This is a condition to avoid aspect 1. Why? Even if DoubleFinger dialog will appear with a small delay, the fact that it was scheduled for the presentation may revoke the active state of the Basic dialog immediately. See in the example the code to present the Basic dialog:

26. Both the Basic and DoubleFinger dialogs are presented in context of the same owner, in this example in context of the Application component (root object). This is the a condition to avoid aspect 2. Note the usage of GetRoot() when the DoubleFinger dialog is presented:

Well I hope it clarifies the behavior.

Best regards

Paul Banach