4

I have a Pivot Control in my WP7 app that by nature responds to left and right swipes to move between the pivot items.

I then want to use the Flick Gesture on a UserControl (a small UI segment on my page) for something else.

My user control does handle the event but so does the Pivot control, so it navigates to the next item. I have not figured out how to stop the event when the usercontrol handles it.

Is it possible to use a sub control with the flick gesture within a WP7 Pivot Control?

eg:

        private void glBlinds_Flick(object sender, FlickGestureEventArgs e)
        {
                //do stuff
                e.Handled = true;
        }
Rodney
  • 5,417
  • 7
  • 54
  • 98

3 Answers3

5

This solution posted recently seems to be working out for people for dealing with gesture conflicts on pano / pivot. You might like to check it out.

Preventing the Pivot or Panorama controls from scrolling

Mick N
  • 14,892
  • 2
  • 35
  • 41
  • Thanks Mick - are you sure it works with the Gesture controls tho? In the comments another user seemed to be having problems with it (I have not tried it) – Rodney Nov 25 '10 at 23:36
  • windows 8 solution is UseOptimizedManipulationRouting="False" – Clinton Ward Dec 31 '14 at 16:42
4

The short answer is don't put a control which supports a gesture on top of another control which also supports the same gesture.

Please see this answer to a very similar question for a slightly longer response: WP7 Toggle switch in a Pivot control?

Community
  • 1
  • 1
Matt Lacey
  • 65,560
  • 11
  • 91
  • 143
  • From a techincal POV I thought that was the whole point of e.Handled = to stop the event bubbling up and being consumed further up? From a Users POV - it's perfectly acceptable - it's like saying you can only have 1 click event per page if the outer frame navigation relies on clicking! There must be a solution? – Rodney Oct 19 '10 at 09:43
  • 1
    From a usability persective this is very hard to do well. It's also hard to make it clear to the user where the boundary for one gesture ends and the next starts. As a rule: don't do this. If you want to break the rule then be aware of the consequences. AFAIK the pivot control does not support a way of handling swipe gestures to override the default behaviour - hopefully/presumably to discourage potentially breaking the default behaviour. Mouse click events and touch gesture events are not directly comparable. don't assume they are - even though the tools call touches clicks. – Matt Lacey Oct 19 '10 at 10:42
  • From a usability POV I don't see why it should be a problem if the UI denotes the boundaries with clear demarkations - ie. if you swipe on THIS element it does x and if you swipe anywhere else it does Y. The user doesn't not know techincally that one control is a child of the other - the navigation elements of the pivot control are at the top - in the old days they would just click on the tab headings to change page, it happens to let them swipe anywhere on the page. It just seems strange that there is no way around this - I have to have swipe gestures and I was planning on using Pivot *sigh* – Rodney Oct 19 '10 at 10:56
  • 1
    For me, a usability fix would be the exact same Pivot control layout but the swipe only works on the headers. Swiping anywhere else would work and the user would never know any different. Thanks for the replies. – Rodney Oct 19 '10 at 10:57
  • From a usability point of view you are doing something different in your pivot to every other pivot. One of the points of having standard behaviour in a control is that it always works the same way. Users will have learnt from using pivots in other apps that they can swipe anywhere to navigate. [No the user won't know it's called a pivot control but they will recognise the look and behaviour.] It's a rule you can break, just be aware of the consequences. The pivot control won't help you break the rule though. – Matt Lacey Oct 19 '10 at 11:14
  • Hmm ok, I guess that leaves me with 2 options - either use Vertical swiping (which does not really make sense in my app) or get rid of the pivot control and use 2 different pages with navigation... I tried intercepting the event and cancelling it but no joy. I'll probably go the Vertical route as the Pivot control is really cool. – Rodney Oct 19 '10 at 11:31
  • 1
    ps - I found this in the UI Design and Interaction Guidelines (although I am still not 100% convinced ;) "Pivot pages must not override the horizontal pan and flick functionality as it collides with the interaction design of the pivot control." – Rodney Oct 19 '10 at 11:38
  • As somebody who was at the WP7 workshop at PDC10, straight from the horses mouth.. the AppHub may/will deny your app if you embed gesture'ie controls inside one another. I believe it was Clint Rutkas who showed a few examples as to why it's usually a really bad idea (i.e. a left/right slider control in a tab). – Erik Kerber Nov 03 '10 at 04:39
  • Correction above: tweeted Clint and he said that it was just discouraged, not disallowed. – Erik Kerber Nov 03 '10 at 17:23
0

I found this works well for incorporating a slider on a pivot item:

LayoutRoot
  Pivot
    PivotItem
      Grid
        Scrollviewer
          [Content goes here, I use another grid]
        Slider

If I skip the grid and place the slider inside the scrollviewer it doesn't work. I stumbled upon this solution as I wanted to support landscape and still have the slider visible / usable.

You might be able to place your small UI segment for the gesture similar to where I placed my slider.

Kevin Burandt
  • 1,970
  • 1
  • 14
  • 10