Search

Silverlight 3 added support for merged dictionaries. Basically, using these, we can split resources over several files, dictionaries. Using them though is nothing different than using resources located in App.xaml or Resources of the current page/control.

Andrew Marshall found that merged dictionaries are not supported by the Silverlight Toolkit’s Themes feature and decided to find a solution and give it to you.

Silverlight 3.0 moved its featureset closer to that of WPF by adding support for merged Resource Dictionaries and Style Inheritance. Without these features, developing custom templates and styles for Silverlight controls can become a bit of a copy-and-paste nightmare. Since I have used the implicit theming feature built into the Silverlight Toolkit to make my Silverlight controls fit into the overall look and feel of this site, I was hoping that these features would enable me to refactor my themes developed for Silverlight 2.0 to be a bit less unwieldy.

Andrej Tozon is continuing with his series "Countdown to Silverlight 3" and now publishes Part 2 - Setting styles and Part 3 - Merged resource dictionaries. If you have missed the first part, here it is - "Countdown to Silverlight 3 #1: Out of Browser applications".

With Silverlight 3 knocking on the door (July 10?) it’s time to offload my Silverlight 3 examples. Not that they would show anything new (since SL3 Beta got out, new features had been demoed by various people to the death), it’s just another perspective or a way to go public with a sample code that’s been piling up on my desktop since the Beta was released. Anyway, this will be in a form of short posts with provided test page and sample code.

Merged Resource Dictionaries provide a way to define and split resources into separate files. By locating application resources in external file we can then reuse them between applications. This feature can be helpful in custom control development, but not only.

In Silverlight 2 resources cannot be factored into separate files and that leads to large App.xaml file holding application-wide shared resources. The same problem exists while developing custom controls. All default style keys must be specified in Themes/Generic.xaml which again leads to very large file.