Tag Archives: wp7

Random ArgumentException in a Windows Phone 7 application

While working on the last update of the 2Day todo-list application for Windows Phone, I encountered a strange bug I wanted to share in this post. The symptoms were very awkward: an ArgumentException where thrown randomly while using the app:

As always when I got that kind of stuff, I try to find out a reproducible set of actions which lead to the crash. Unfortunately in this case it wasn’t that easy.

After a couple of try, I found out I could reproduce the problem by doing the same set of actions many times:

  • launch 2Day
  • navigate to the details view of a task
  • go back to the home screen
  • navigate to the details view of another task
The crash then happened between 1 and 20 tries. The stacktrace wasn’t very helpful:
at MS.Internal.XcpImports.CheckHResult(UInt32 hr)
at MS.Internal.XcpImports.Collection_AddValue[T](PresentationFrameworkCollection`1 collection, CValue value)
at MS.Internal.XcpImports.Collection_AddDependencyObject[T](PresentationFrameworkCollection`1 collection, DependencyObject value)
at System.Windows.PresentationFrameworkCollection`1.AddDependencyObject(DependencyObject value)
at System.Windows.Controls.UIElementCollection.AddInternal(UIElement value)
at System.Windows.PresentationFrameworkCollection`1.Add(UIElement value)
at System.Windows.Controls.ItemsControl.AddVisualChild(Int32 index, DependencyObject container, Boolean needPrepareContainer)
at System.Windows.Controls.ItemsControl.AddContainers()
at System.Windows.Controls.ItemsControl.RecreateVisualChildren(IntPtr unmanagedObj)
at MS.Internal.XcpImports.MeasureOverrideNative(IntPtr element, Single inWidth, Single inHeight, Single& outWidth, Single& outHeight)
at MS.Internal.XcpImports.FrameworkElement_MeasureOverride(FrameworkElement element, Size availableSize)
at System.Windows.FrameworkElement.MeasureOverride(Size availableSize)
at Microsoft.Phone.Controls.Pivot.MeasureOverride(Size availableSize)
at System.Windows.FrameworkElement.MeasureOverride(IntPtr nativeTarget, Double inWidth, Double inHeight, Double& outWidth, Double& outHeight)
After some time spend on the Internet, I found out this post on StackOverflow. It basically told me something could be wrong with the naming of the elements in the XAML. Actually I did change some XAML in 2Day in order to change the layout of the task create/edit page:
During that refactoring I changed the way the notes are displayed and I created a UserControl for that purpose. Ultimately, I found out that this control was named: it has a x:Name set at the top of the XAML (note the line 8 in the following sample):

I needed that because I wanted to databind the Text property of a TextBox on a Dependency Property defined on the control itself:

Because the post on StackOverflow talked about naming controls, I thought that could be the cause of the error. It it was actually ! Removing this single piece of XAML (and changing the binding a little bit) removed the crash from the app !

This is definitively the strangest bug I’ve seen on the Windows Phone platform… Hope it helps 🙂

If you want to give a try to a fast & fluid todo-list app for Windows Phone 7, feel free to download 2Day:

Introducing 2Day: a fast & fluid todo-list WP7 app

Today is an important day for me. A couple of days ago, my colleague Charlotte and me released a new Windows Phone 7 app: 2Day. Because we put a lot of energy in the design and the realization of this app, I wanted to showcase it in a post 🙂

2Day is a todo-list app we have been working on for several months. It can be summarized the following way:

  • fast & fluid: 2Day is fast to run & fast to use because of many tricks (you can add a task right from your home screen)
  • connected: 2Day supports both ToodleDo and Exchange synchronization + SkyDrive as an online backup storage
  • engaged: we listen feedback very carefully and users can reach us by mail, Twitter or UserVoice
2Day is available in English, Italian, Spanish, German and French !

click for full-resolution image

I will without any doubt write some articles about the technical story behind 2Day. They are many interesting things I would like to share with you.

Please, if you appreciate my blog and think that 2Day is cool spread the word 🙂

For more information:

You can use the following QR-code to go directly to the marketplace from your mobile:

Many thanks,

WP7 performance tip: translate transforms

In my previous blog post, I described a control called the PivotIndicator.

The PivotIndicator is made of a small rectangle that is animated on an X axis: its position is updated every time the selected item of the Pivot changes. Here is the code which setup this animation:

var border = new Border { /* init properties... */ };
var animation = new DoubleAnimation
    Duration = new Duration(TimeSpan.FromSeconds(0.5)),

Storyboard.SetTarget(this.animation, this.border);
Storyboard.SetTargetProperty(this.animation, new PropertyPath(Canvas.LeftProperty));

The problem I noticed was that this animation wasn’t fluid. In particular, when the PivotItem contains a lot of items…

As you probably already know, the WP7 platform introduces a Compositor thread. This thread does not exist in the “desktop” version of Silverlight. The idea is that this thread can handle simple animations independently from the UI thread (which can be quite busy…) and leverage the GPU.

Now, in my code, I’m using a DoubleAnimation to animate a Canvas.Left property. What is wrong with that ? Actually, the problem is the property I’m animating, not the animation itself. When I setup an animation using Canvas.Left, there is absolutely no way the Compositor thread can handle it. Why ?

Because when the property changes, it triggers a layout update in the Canvas. This process is totally “CPU-bound” and executes on the UI thread. The dependency property changes, it calls InvalidateLayout which update the position of the item (by calling .Arrange() on each of its child). In this case, the GPU & the compositor thread cannot be used.

Now, the trick is to do the exact same animation with a different code:

var border = new Border { /* init properties... */ };
var translateTransform = new TranslateTransform();
border.RenderTransform = translateTransform;
var animation = new DoubleAnimation
    Duration = new Duration(TimeSpan.FromSeconds(0.5)),

Storyboard.SetTarget(this.animation, translateTransform);
Storyboard.SetTargetProperty(this.animation, new PropertyPath(TranslateTransform.XProperty));

Notice that all I change is using an TranslateTransform: the target of the animation is not the border but the translate transform it self. A TranslateTransform is an operation which can be handled by the GPU. Now, his animation is handled by the Compositor Thread and will be fluid even though the UI thread gets very busy !

Hope it helps 🙂