WP7 Application crash (in buy now!)

I followed the advice on msdn about how to add a buy now button to my Windows phone app.

Today, I noticed I had a crash in one of our applications, and downloaded the stack trace.

On the stack is MarketplaceDetailTask.Show

A bit of searching and trial and error shows that if the user executes this quickly (by double tapping the button the handler is on) the program will crash.

I’m guessing the user didn’t buy.

Follow up:

To solve this, I added the following belt and braces code:

private void OnPurchase(object sender, RoutedEventArgs e)
        {
            btnbuynow.IsEnabled = false;
            try
            {
                _marketPlaceDetailTask.Show();
            }
            catch (InvalidOperationException ex)
            {
            }
        }

This disables the button which prevents subsequent button presses while transitioning.  I catch the exception thrown for good measure, though as no type of exception is documented to be raised, maybe I should just catch everything.

I then reenable the buy now button whenever the page is navigated to as follows:

protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
    btnbuynow.IsEnabled = true;
    base.OnNavigatedTo(e);
}

ScrollViewer Inertia and ManipulationCompleted

Today, I was solving a problem with a ScrollViewer.  I want to simulate a continuously scrolling view of the world for our application “Terminator”

I was attempting to handle the scrolling stop in the ManipulationCompleted event handler.  The MSDN documentation on ManipulationCompleted states “Occurs when a manipulation and inertia on the UIElement is complete.”

This is clearly not the case, as it appears to fire when the direct manipulation stops, but the inertia hasn’t.

Luckily there’s a way to check when scrolling stops on Peter Torr’s blog.

In addition, I had hoped to be able to utilize ManipulationDelta to find out where the scroll viewer was now.  This also was a dead end, wasting hours of work.  My requirement was to be notified of changes to HorizontalOffset on the ScrollViewer.

Alas, there is no event raised for that, however, I came across this useful code on Beat Kiener’s blog to Listen to DependencyProperty changes on WP7 and Silverlight.

With that, I can now know the current position (when Mango decides to update it) of my scroll bar, and react accordingly.

How can it be this difficult?  When apps only bring in tiny amounts of money, the inordinate effort to polish off an app seems completely disproportionate to the reward for doing it right.  Not to mention the amount of research that needs to go in to find all of these little fixes.