Author: James Ashley

A common question on WP7 message boards and mailing lists concerns how to cancel a pivot control’s built-in page swiping when you have another control in the pivot that takes swipe gestures: for instance, a Slider!

The standard Microsoft response to these queries is that you shouldn’t do it.  It creates UX confusion and is a “bad practice.”  The assumption is that users don’t think contextually, and will expect swiping to always do the same thing on a page.  This is one of those “sounds good enough” answers, and seems eminently reasonable with respect to a slider control inside a pivot panel.  Besides, you can always just orient your slider vertically, so there is even an out. 

On the other hand, WP7 textboxes use hold-and-swipe to manipulate the cursor in a textbox.  Is it poor UX or a bad practice to use textboxes inside of a pivot control?  Should I try to find a way to orient my textboxes vertically?  What about the Toggle Switch control?

Consider also that swiping is the quintessential phone gesture.  Every new WP7 control in 2011 will attempt to take advantage of it.  It would be a shame if we couldn’t use any of them with the pivot.

This post will address how to do the unspeakable: add a working, horizontally oriented slider to a pivot control.  If you understand how to add a slider to a pivot, you will be able to add any sort of control to a pivot.  For additional takes on this “Don’t Try This At Home” topic you should read Derik Whittaker’s post as well as Miloud B’s post.

In a nutshell, the keys to making this work are to use the IsHitTestVisible property of the pivot control in order to disable swiping.  Then use the static Touch class’s FrameReported event to determine when to re-enable it.

Create a new project in Visual Studio.  If the Pivot control is not available in your toolbox, right click on the toolbox and select “Choose Items…”  Scroll until you find the Pivot and select it.  Open MainPage.xaml in design view.  Drag the Pivot control into the Content grid.  Grab the sizing handles for the Pivot and drag them around until the Pivot fills the Content grid (everything under the Application Title and Page Title textblocks).

Two pivot panels are initially stubbed in for the Pivot control.  Drag a Slider control into the first panel (“item1”).  If you run the application now, you will encounter strange behavior in which the slider bar is successfully moved when you swipe it, but at the same time the pivot panel also attempts to page to a new panel.

To fix this, handle your slider control’s ManipulationStarted event and set the pivot’s IsHitTestVisible property to false in order to disable it while the swipe for the Slider is being handled. 

When the swipe is completed, you will need to re-enable the pivot.  You cannot do this on the MouseLeftButtonUp event since this gets disabled on all child controls when you set IsHitTestVisible to false on a container.  Putting it in the ManipulationCompleted event is possible, but results in inconsistent behavior.

Instead, take advantage of the lower level touch API.  Check to see when an up touch gesture occurs over your slider  and set the pivot’s IsHitTestVisible property to true when it does.  This can be hooked up in the page constructor like so:

Touch.FrameReported += (s, e) =>
{
    if (e.GetPrimaryTouchPoint(slider1).Action == TouchAction.Up)
    { 
        pivot1.IsHitTestVisible = true; 
    }
};

Here is the relevant XAML:

<!--ContentPanel - place additional content here-->
<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
    <controls:Pivot  HorizontalAlignment="Stretch" Margin="6,6,0,0" 
                        Name="pivot1" Title="pivot" 
                        VerticalAlignment="Top" Height="595">
        <controls:PivotItem Header="item1">
            <Grid>
                <Slider  Height="107" HorizontalAlignment="Left" 
                            Margin="-4,109,0,0" Name="slider1" 
                            VerticalAlignment="Top" Width="460" 
                            SmallChange="1" 
                            Maximum="100" 
                            Value="30" 
            ManipulationStarted="slider1_ManipulationStarted" />
            </Grid>
        </controls:PivotItem>
        <controls:PivotItem Header="item2">
            <Grid />
        </controls:PivotItem>
    </controls:Pivot>
</Grid>

And here is the code-behind:

public MainPage()
{
    InitializeComponent();
    Touch.FrameReported += (s, e) =>
    {
        if (e.GetPrimaryTouchPoint(slider1).Action == TouchAction.Up)
        { 
            pivot1.IsHitTestVisible = true; 
        }
    };
}

private void slider1_ManipulationStarted(object sender
    , ManipulationStartedEventArgs e)
{
    pivot1.IsHitTestVisible = false;
}

One of the questions every developer must face when a new technology like WP7 comes on the scene is whether to jump onboard early (in the CTP and Beta stages) or wait until a platform RTMs.  The advantage of the former is that one has a longer lead time to learn the technology and establish oneself as an authority on the technology inside one’s company or on the web.  The advantage of the latter is that one doesn’t waste time learning things about the technology that are in flux and may go away; instead one can wait for the experts to say what they have to say and learn from that.

A possible advantage to deferring the groking of a new technology is that one also has less to unlearn.  Early adopters often make the mistake of assuming that they do not have to re-examine what they already know when the technology RTMs.  The problem for those who defer learning new technologies is that, if they are not careful, they may inherit the bad information disseminated by those early adopters and insiders, and suddenly we are all stuck in a situation where what counts as common knowledge is simply wrong.

Probably the worst case of this for Windows Phone developers occurred with launchers and choosers.  The original metaphor seemed clear enough: launchers are fire-and-forget components, choosers return information.  This turns out not to be completely true, however.  Save operations, which are considered launchers, must return information about whether each save was successful.  They aren’t really fire-and-forget. 

Another early lesson WP7 developers learned was that all launchers and choosers cause an application to tombstone – and thus was created one of the most obscure and difficult aspects of Windows Phone development.  As WP7 went from Beta to RTM, however, it was decided that this didn’t always make sense.  Recovering from tombstoning is time-consuming.  Why force an app to tombstone for something like the CameraCaptureTask when the user will most likely return to the application immediately after the task is completed?  To find out more about deferred tombstoning, see Why Deactivated is Not the Same as Tombstoning.

Just to make things a little more complicated, it isn’t just the four choosers which turn out to not force tombstoning.  MediaPlayerLauncher, one of the eleven launchers, also implements deferred tombstoning.  The PhoneCallTask also does not throw an application into tombstoning mode (additionally, it also never seems to trigger the Deactivated event).  Incoming phone calls, outgoing phone calls, the five choosers and MediaPlayerLauncher all merely suspend (or pause) the application, keeping all the pages along with their state in memory.

If you are confused, welcome to the club.  The original metaphor of having launchers and choosers broke down bit by bit through subsequent iterations of the Windows Phone platform.  Experts quote each other based on these different iterations.  After a while, no one is sure anymore exactly how launchers and choosers work.

The solution, naturally, is to trust but verify everything you read.  You can find out whether an application is actually tombstoned when a task (the generic name for both launchers and choosers) is initiated by placing a simple debug message in the constructor of the page that launches the task.  If the constructor is called when you press back from the task, then your application was tombstoned.  If the constructor is not called, then you know the page has been retained in memory and tombstoning did not occur.

Once you have verified something like this, always write it down somewhere.  Here’s the chart I keep for myself to help remember the behavior of various launchers and choosers.  It is for the RTM version of Windows Phone only.  Please take it with a grain of salt.