That’s why it’s called the default *value* instead of default *values* [Tip: The default value of a DependencyProperty is shared by all instances of the class that registers it]

This blog has moved to a new location and comments have been disabled.

All old posts, new posts, and comments can be found on The blog of

See you there!

Comments (9)
  1. gmurray says:


    Maybe you can assist me. I’m having some issues figuring out the best pattern for initializing a collection typed dependency property in Silverlight without disabling its ability to have its default value set from a style, see:

    Or is there another approach you would recommend? Or perhaps I’m misinterpreting the way its behaving ๐Ÿ˜‰


  2. David Anson says:


    The experience you discuss in your blog post is part of the reason that Chart’s Palette works as it does today. ๐Ÿ™‚ While I haven’t played around with this area recently (i.e., the last year or so), my recollection from when I *did* (2 versions of Silverlight ago, by the way) was that things behave as you describe. I decided the behavior pattern that Palette currently uses was the most flexible – though it’s unfortunate that some design tools don’t work seamlessly with it.

    So if you find a better alternative here, I’d definitely be interested in learning about it!

  3. gmurray says:

    Thanks, I’ll let you know if I stumble on anything. I was reading one account where someone was trying to auto-initialize collection-typed attached properties with new collection instances so as to support direct item content in Xaml, and they were successful if they registered a different name for the backing dependency property than the CLR property fronting it, thus forcing the Xaml parser to reflect against the CLR and invoke the clr getter (which could initialize the collection if null). But this approach seems like it would be lacking in many ways (not to mention being hacky) for a normal dependency property. Interesting behavior though…

  4. gmurray says:

    I think Silverlight 4 helps here since it supports ISupportInitialize. My understanding is that BeginInit will be called before any of the Xaml attributes are parsed, and EndInit will get called before the styles are applied. And if this is truly case it should be possible to set a local value in BeginInit so that it is present during the parse of the element, but then to clear the local value in EndInit if no items are actually added to the collection. In this manner the style values will not be overridden precedence-wise. What do you think of this approach? I’ve successfully run some preliminary tests of this method, but am still tracking down an oddity with the design surface.

  5. David Anson says:


    Very clever! Though perhaps a little TOO clever – let me know how the design-time oddity works out. ๐Ÿ™‚

  6. gmurray says:

    Yeah, although this approach works for runtime, the designer plays foul by applying the style as you are typing. So you end up editing the collection associated with the style when you use direct collection content, which is "interesting".

    I’m pretty sure I can get around these issues by using a read only collection that lets its owning class create a new writable copy on mutation, but things are getting more complex ๐Ÿ˜‰

  7. gmurray says:


    Here’s some more details about what I’ve been trying.

    Based on how the designer seems to be working, however, I’m not certain how much it helps. Does seem to fix the runtime problem though. In the end, it would be nice to coerce the tools’ collection editors into generating the Xaml at the end of the post, if that’s possible.

  8. David Anson says:


    I’ve passed your feedback on internally – if I hear anything helpful back, I’ll let you know!

  9. gmurray says:

    Thanks! It’s always possible I’m just doing something wrong, or am unaware of some other functionality also ๐Ÿ˜‰

Comments are closed.

Skip to main content