bug

10
Aug
2012

wait_fences: failed to receive reply: 10004003

This error is cryptic and can have any number of causes, but the most common are:

  • Performing animations when the view isn’t on screen (use viewDidAppear, not viewWillAppear)
  • Failing to call super when overriding a method
  • Calling something in the UI from a thread other than the main UI one
  • Calling UI methods that dramatically change the view (such as presenting / hiding main views) too quickly
  • Calling UI methods before an alert has been dismissed

Basically the error is related to the UI. The message appearing in the output may not reflect the code that actually triggered it – so to debug you need to isolate the code that’s causing it. Your first port of call should be callbacks from alerts, or other popups. For me it was the UIImagePicker, I fixed it like so:

protected void FinishedPickingMedia(object sender, UIImagePickerMediaPickedEventArgs e)
{
    var picker = sender as UIImagePickerController;

    if (picker == null)
        return;

    picker.DismissModalViewControllerAnimated(true);
    if (picker == _picker)
	_picker = null;

    // Work with the image here

    // Bug fix for fences issue
    BeginInvokeOnMainThread(() =>
    {
        // CODE THAT INTERACTS WITH THE UI HERE
    });
}

The pertinent code is the BeginInvokeOnMainThread block, this is fixing the wait_fences issue. It looks like the callback method isn’t being executed on the UI thread. I’m not sure if this is an iOS SDK thing, or a quirk added by MonoTouch. It could also be that the picker is still animating away when I start tweaking the UI, causing the issue. For example messing about with the UI in the Clicked event of a UIAlertView can sometimes cause minor issues, moving the code to the Dismissed event fixes the issues completely.

Posted by Dan in C#, iOS, MonoTouch, 0 comments
04
Jun
2011

LongListSelector ListFooterTemplate {Binding} Resolves to NULL

It’s quite common to have a ‘More’ button at the end of long lists within a LongListSelector. The problem is the template inexplicably doesn’t cascade the DataContext, so you have no access to the collection to trigger a more command. Fortunately the workaround is simple, albeit you can’t use pre-defined DataTemplates.

<toolkit:LongListSelector x:Name="SimilarList" ItemTemplate="{StaticResource GeneralCatalogListItemTemplate}" SelectionChanged="SimilarList_SelectionChanged" DataContext="{StaticResource dummyCatalogTitlesList}" ItemsSource="{Binding}" IsFlatList="True">
    <toolkit:LongListSelector.ListFooterTemplate>
        <DataTemplate>
            <bindings:CommandButton Content="More..." Command="{StaticResource moreCommand}" DataContext="{Binding ElementName=SimilarList, Path=DataContext}" CommandParameter="{Binding}" />
        </DataTemplate>
    </toolkit:LongListSelector.ListFooterTemplate>
</toolkit:LongListSelector>

You need to give your list a name, then when setting the DataContext for your controls make sure to provide the ElementName as seen above.

I’m not sure why the other templates cascade correctly and this one doesn’t, but I’m hopeful it’ll be fixed in a future release of the toolkit. As an aside there is a fairly clean workaround if/when MS add the Freezable class to WP7.

Posted by Dan in C#, Windows Phone, 2 comments
29
May
2011

Isolated Storage Settings In WP7

Recently I had a problem with Isolated Storage Settings on WP7 – the entire collection appeared to be wiped every single time I restarted the app. The problem turned out to be the deserialization stage of IsolatedStorageSettings, in essence if any object can’t be re-instantiated, then the entire collection is inaccessible. The collection will work correctly until you attempt to retrieve something that can’t be instantiated.

At the bare minimum the constructor of your class must be public.

All non-public properties will also fail to be restored, resulting in a rather empty object instance when you come to load the values that should have been saved (and have been… they just don’t come back). Be very careful with this issue, you may not notice the problem until it’s too late.

Posted by Dan in C#, Windows Phone, 1 comment