0

I am making an app with panoramic view where the user can select a color hue, saturation and value from a color wheel and SV graph like this: https://i.stack.imgur.com/wFwcL.jpg https://i.stack.imgur.com/FJgbm.jpg

The user can either tap or drag a pointer across the square, coordinates determine the values. But when they drag(mousemove), the app will also slide to the next screen.

Is there a way I can disable the slide to next page if the sliding is done within the graph? It should function normally outside the graph area. Something like a disable panoramic slide function that can be implemented within the graphs mousemove event handler?

Putting the hue wheel and SV-graph on separate pages will dramatically reduce the combined dynamic functionality of the two so I'd prefer them to be on one panoramic page.

JasonMArcher
  • 14,195
  • 22
  • 56
  • 52
user2175326
  • 1

1 Answers1

0

This doesn't seem a good use of a panorama. This will lead to "gesture competition" between the touch action on the controls and the panorama itself. The same problem arises if you use a Pivot control.

If you want Hue and SV on the same page, why don't you put them on the same page and allow switching of the mode by a button, say on the app bar?

You can have both controls in the XAML tree and show the one which is active and hide the other. You can do this by changing the Visibility of each control.

Paul Annetts
  • 9,554
  • 1
  • 27
  • 43
  • The idea behind disabling the panorama controls within the graph is to avoid gesture competition. Hiding either and allowing to switch seems like a good alternative that I'll consider. Downside is that it'd have to be on a separate page where the panorama page contains more elements than just these two graphs that I'd like to keep together. These are just the only two that use dragging gestures. Besides your suggestion for alternative design, are there ways to locally disable panoramic controls or give the elements controls a higher priority? – user2175326 Mar 16 '13 at 12:48