Sunday 20 May 2012

More bugs in the Toolkit ListPicker

We recently updated our Chromatic Tuner app, Tune Up, and after the update using the latest fixes for the Silverlight Toolkit was disappointed to find some new stack traces on the control panel.

As usual it’s a navigation bug, this time caused by a storyboard completing after something else has happened, in this case, someone pressed the start button after the navigation began.

As a result, the code in PickerPage.xaml.cs calls NavigationService.GoBack(); in the OnNavigatedTo handler.

Then the storyboard completes, and NavigationService.GoBack(); is called again while navigating.  We all know this is going straight to the exception handler.

The fix and issue are at http://silverlight.codeplex.com/workitem/10769 but I’ll duplicate it here.

private void OnClosedStoryboardCompleted(object sender, EventArgs e)
{
// Close the picker page
if (NavigationService.CanGoBack)
{
// Only do this if we can go back, or we crash
// navigate to start menu before this happens provokes.
NavigationService.GoBack();
}
}



But wait, there’s more!


While trying to diagnose this problem, I was playing around with the ListPicker trying to figure out exactly what might be going on, and I found another problem.


Immediately after you make your selection, the transition begins, and effectively you’ve made your selection.


But it’s actually possible to click on another item, and select that during the transition!  I consider this undesirable behaviour too.  You made your choice, and the transition began, yet you can change it at the last minute?  BZZZZ.  Wrong.


Here’s the fix for that one, again in ListPickerPage.xaml.cs:


private void ClosePickerPage()
{
IsOpen = false;
// AAW: disable picker on exit.
Picker.IsEnabled = false;
}

1 comment:

  1. Hey there, thanks for using the Toolkit as well as reporting bugs and digging into them. We've pushed fixes for both issues up to CodePlex and hope to soon have an updated NuGet package up as well.

    FYI the 2nd fix that went in was slightly different, setting IsEnabled = false causes all the items to go into their disabled state which doesn't visually match the 1st party experience so instead we've set IsHitTestVisible to false.

    ReplyDelete