Working with collection-typed Dependency Properties, part 2

April 27, 2010

In my last post on this subject, I was trying to track down a good way to avoid setting the default for a collection typed Dependency Property in the constructor. See my the other post as to why this makes the property harder to style. I’ve come up with some interesting ideas, but there are still some interesting quirks with how the Xaml design surfaces treat these collections and the associated styles.

The root problem I was trying to address is that when you have xaml such as this:

<local:Palette x:Name="thePalette">
    <local:Palette.Colors>
        <Color>Blue</Color>
        <Color>Orange</Color>
    </local:Palette.Colors>
</local:Palette>

And you have a Color dependency property that is not initialized in the default value or the constructor but is initialized in the style:

<Setter Property="Colors">
    <Setter.Value>
        <local:ColorCollection>
            <Color>Red</Color>
            <Color>Blue</Color>
        </local:ColorCollection>
    </Setter.Value>
</Setter>

Then, oddly, things will appear to work correctly in the designer. Meanwhile, at runtime, as expected, when the Xaml parser goes to add the colors to the Colors property it will find that the Colors property is null.

Silverlight 4 actually gives a good way to avoid this behavior in the form of the ISupportInitialize event. When we have our control implement this class ISupportInitialize.BeginInit will be called when the Xaml parser starts parsing the element, and ISupportInitialize.EndInit will get called when the Xaml parser finishes parsing the element, before the style is applied. Thus, if we want to ensure that there is an empty local collection for the parser to fill, but not leave the collection as a local value if the parse doesn’t find any local values (so that the style precedence properties can apply), we can do something like this:

        private ColorCollection _initialColors =
            new ColorCollection();

        public void BeginInit()
        {
            if (ReadLocalValue(ColorsProperty) ==
                DependencyProperty.UnsetValue)
            {
                _initialColors.Clear();
                Colors = _initialColors;
            }
        }

        public void EndInit()
        {
            if (GetValue(ColorsProperty) == _initialColors &&
                _initialColors.Count == 0)
            {
                ClearValue(ColorsProperty);
            }
            UpdateColors();
        }

Which will basically set a local value as the Xaml parser begins to parse the element, but if no items are added to the collection, clear the value when done parsing, so that the style values can take precedence.

This seems to work for fixing the runtime problem. However, there seem to be other problems with creating style-able collection properties when it comes to the designer. If you, for example start typing out the Palette as above, the designer will apply its style before you even get to the Colors property, so, when you are adding the items to the Colors property collection, you will be modifying the collection from the default style of the Palette, so the Colors properties all Palette instances will be affected. Fun, huh? So I’m left wondering if its a good idea currently to try and create style-able collection-typed Dependency Properties with the current tool support, given their current behavior.

It would nice if we could somehow indicate to Blend/VS that this is the only correct way to specify the Colors collection in Xaml:

<local:Palette x:Name="thePalette">
    <local:Palette.Colors>
        <local:ColorCollection>
            <Color>Blue</Color>
            <Color>Orange</Color>
        </local:ColorCollection>
    </local:Palette.Colors>
</local:Palette>

But I haven’t come across a way to do this yet….

Advertisements

Dead PS3. A case for cloud storage for save games.

April 26, 2010

My PS3 unceremoniously died last night, making me sad. The fact that its out of warranty and I need to pay to fix it makes me sad. The fact that I’ll likely have to wait 6 weeks makes me even sadder. But what makes me most sad is that all my save games will not survive the process. There is an easy and useful mechanism for backing up save games for the PS3, but I cannot use this if I cannot get into the system’s OS (it’s that broken).

I cannot take the hdd out and extract the save games because the drive is heavily protected and encrypted. This is understandable because having user modifiable save games would introduce an attack vector that Sony would rather not have to worry about, but it does present some rather ugly usability issues. Above and beyond the fact that I’m now unable to extract my save games, even if I had had the foresight to do this, some games do not allow their saves to be transferred to a different system than which originally hosted them.

I believe this must be to prevent some sort of cheating or abuse of the trophy system. Apparently some games can be transitioned between systems, but then disable certain features, such as trophies, for that save file. So, this brings me to my point. Sony is researching ways to monetize PSN by all rumors, so here’s an easy one:

I would pay a small recurring sum to have my save games automatically synchronized with PSN and associated with my account so that I could use them from any PS3 associated with my account. This would be a really nice value add. It would certainly make sense especially for games that you can play on both the PSP and the PS3 (ps1 classics), imagine automatically sharing a save file for a game you were playing on both devices? So, a nice feature for disaster scenarios AND a value add to the platform. Sounds good? Now to wait 6 weeks before having to replay the games I was in progress of completing.


Interesting IOC, AOP news

July 17, 2008

Was just reading Andrew’s blog and it seems like Microsoft has snapped up the founder of the Castle Project for their projects. I think you can really tell how different a company MS has become in recent years. It seems as if they snap up the brightest college grads, and prowl the .NET architecture community for strategic hirings to improve their offerings. This is really putting their gargantuan resources to use for the good of .NET. I only wish they would apply some of this “leverage the community” zeal to their operating system. But I’m just really excited that this should mean some well thought out IOC and AOP offerings from microsoft in the future.

I’m hoping, also, that these new patterns don’t remain isolated in enterprise libraries or application blocks. Some of these concepts deserve to be first class objects in the clr and supported languages. What I’m personally hoping is that, at some point, we get some compile time weaving extensibility support in Visual Studio, so that we can make syntactical extensions to the languages at a more fundamental level. It’s rather hard to interface dynamic proxy based AOP with opaque frameworks. We really need some compile-time IL modification going on, or at least some way to intercept object creation, if you are relegating this to a framework.