Proper usage of Merged Resource Dictionaries in Si

问题:

As I read: http://msdn.microsoft.com/en-us/library/cc903952(VS.95).aspx, specifically the section labeled "Forward References With a ResourceDictionary":

Static resource references from within any given resource dictionary must reference a resource that has already been defined lexically before the resource reference. Forward references cannot be resolved by a static resource reference. For this reason, if you use static resource references, you must design your resource dictionary structure such that resources intended for further by-resource use are defined at or near the beginning of each respective resource dictionary.

Does this mean that I cannot do something like this in my App.xaml:

<Application.Resources>
    <ResourceDictionary>
        <ResourceDictionary.MergedDictionaries>
            <ResourceDictionary Source="Assets/Colors.xaml"/>
            <ResourceDictionary Source="Assets/Brushes.xaml"/>
        </ResourceDictionary.MergedDictionaries>
    </ResourceDictionary>
</Application.Resources>

Where Brushes.xaml contains SolidColorBrush, LinearColorBrush, etc, definitions that refer to the colors defined in Colors.xaml ?

e.g.

<SolidColorBrush x:Key="OrangeRedBrush" Color="{StaticResource AppOrangeRed}"/>

?

I define my colors in Colors.xaml like:

<Color x:Key="AppOrangeRed">#FFBF3C1F</Color>

I'm getting a runtime error that states it cannot find a resource with key 'AppOrangeRed' for instance.

What are the best practices for organizing Colors and Brushes so they can be reused (where appropriate, and I understand that colors are structs and brushes are reference objects, explained in http://weblogs.manas.com.ar/spalladino/2009/03/02/silverlight-xaml-guidelines/)

Thanks Rob

回答1:

I understand it now a little clearer. If you have multiple application-scope resources that sometimes refer to each other, you need to (1) order them in the master dictionary declared in App.xaml, AND you need to include in each file a section that pulls in the dependent pieces. So if I have three files for instance, Brushes.xaml, ScrollViewerStyles.xaml, and ComboBoxStyles.xaml, and ComboBoxStyles.xaml depends on the former two, I would need to simply add to the top of that file:

<ResourceDictionary.MergedDictionaries>
    <ResourceDictionary Source="Brushes.xaml"/>
    <ResourceDictionary Source="ScrollViewerStyles.xaml"/>
</ResourceDictionary.MergedDictionaries>

回答2:

Rob,

I understand the documentation the same way that you do. I noticed that it is also possible to swap the MergedDictionaries like so, and still receive the same runtime exception:

<Application.Resources>
    <ResourceDictionary>
        <ResourceDictionary.MergedDictionaries>
            <ResourceDictionary Source="Assets/Brushes.xaml"/>
            <ResourceDictionary Source="Assets/Colors.xaml"/>
        </ResourceDictionary.MergedDictionaries>
    </ResourceDictionary>
</Application.Resources>

From the documentation under "Merged Resource Dictionaries" :

In terms of the lookup sequence, a MergedDictionaries dictionary is checked only after checking all the keyed resources of the ResourceDictionary that declared MergedDictionaries. Then, each of the dictionaries within MergedDictionaries is checked, in the inverse of the order that they are declared within the MergedDictionaries property. In other words, the retrieval logic from within the collection of merged resource dictionaries is last in, first out.

It seems like you can override certain Keys defined in ResourceDictionaries by including them in this order, but you're not able to reference a style from one dictionary defined before another in the lookup sequence. This is frustrating and not intuitive.

I guess this would be useful if you had a collection of "blue" styles and wanted to override them with a set of "orange" styles for a different client. You would accomplish this by including the orange keys below the blue keys in your MergedDictionaries collection, so they are found first in the Resource lookup sequence.

Anyways, I share your frustration and hope for a feature like this at some point in the near future.