A FindResource implementation for Silverlight

Here’s an interesting omission in Silverlight that I stumbled upon today: Silverlight doesn’t provide you with a way to do a hierarchical resource look-up in code.

You can do it in XAML. Write

<Grid>
    <Grid.Resources>
        <Style x:Key="MyStyle>
        </Style>
    </Grid.Resources>
    <DockPanel>
        <Button>
            <TextBlock Style="{StaticResource MyStyle}"/>
        </Button>
    </DockPanel>
</Grid>

and the TextBlock will find the appropriate style in the Grid’s resource dictionary, even though it’s several layers up the hierarchy. And if the resource isn’t found in any of the parent elements, StaticResource will then look in the Application’s Resource Dictionary.

But, whereas WPF provides the TryFindResource method to do the same kind of look-up in code, the best you can do in Silverlight is

element.ResourceDictionary[“MyStyle”]

and that returns null if the resource isn’t in the element’s own ResourceDictionary. 

No matter. It’s easy to a proper lookup yourself:

public static class FrameworkElementExtensions
{
    public static object TryFindResource(this FrameworkElement element, object resourceKey)
    {
        var currentElement = element;

        while (currentElement != null)
        {
            var resource = currentElement.Resources[resourceKey];
            if (resource != null)
            {
                return resource;
            }

            currentElement = currentElement.Parent as FrameworkElement;
        }

        return Application.Current.Resources[resourceKey];
    }
}

With that in place

textBox.TryFindResource("MyStyle");

will do what you expect.

Which of course makes me wonder why this was omitted from Silverlight in the first place. Am I missing something?

(Simon Squared) x n: The Multi-player Challenge

A new year, a new challenge.

The end of 2010 found me scrambling to build a Windows Phone 7 game in 3 days using the XNA framework, spurred on by a competition deadline and the potential reward of a $10,000 prize. The challenge was to “build something that developers will love”, and who doesn’t love reading of a race against the clock?

Well, I got the game done (Ok, maybe not done done – it will still stand some polishing) only to find the deadline moved by two months, and thus my unique selling point rendered an unlovely shade of void. So I need a new challenge, a bigger, a bolder challenge.

How about making a multi-player version of the game?

Using GPS to locate players nearby?

In 3 days?

Oh, and I nearly forgot the geeky dessert topping: I’ll be using Windows Azure to pull it all together.

Now, just to be clear, my calendar doesn’t contain three consecutive day-sized gaps, so these 3 days will have to be spread out over the next couple of weeks. In betweenwhiles, I can’t guarantee that my eye won’t stray to the MSDN pages about Windows Azure, or that my brain won’t allocate a background thread to designing message protocols. But I will promise to keep my Visual Studio solution firmly shut whilst the clock is not ticking.