Sharing Application Resources in WPF

Question

From this page, I read:

If your application uses custom controls and defines resources in a ResourceDictionary (or XAML Resources node), it is recommended that you either define the resources at the Application or Window object level, or define them in the default theme for the custom controls. Defining resources in a custom control's ResourceDictionary imposes a performance impact for every instance of that control.

Ok... now, I have a UserControl that defines the following resources:

<UserControl ...>
    <UserControl.Resources>
        <Namespace:ImagesConverter x:Key="ImagesConverter" ...
        <Storyboard x:Key="AnimationHide" ...
    </UserControl.Resources>

So, because of the fact I'm creating not less than 100 instances of them at runtime, as the MSDN tutorial says, it would be better to move those resources ad MainWindow or App level. Where's the best location to move them to? MainWindow level, App level or resource file? And why?

And then... how can I use them from their new location? Let's say I have this code inside my UserControl:

m_AnimationHide = (Storyboard)Resources["AnimationHide"];

How should I modify it to reflect those changes? And how should I modify the following UserControl XAML snippet instead?

Source="{Binding Source={x:Static Properties:Resources.MyImage}, Converter={StaticResource ImagesConverter}}"

score 5 · Accepted Answer · edited May 14 '14 at 20:47

Personally, I prefer to use App.xaml or seperate ResourceDictionary over adding them all to the Window.Resources, this eliminates clutter in your Window xaml.

This also allows you to easily create Themes for you application as you have them all in one place, so you can copy your existing ResourceDictionary change brush colors etc, the you can choose what ResourceDictionary you want to load and and easily change the entire apperance of your application.

As for accessing the Resouces in your Usercontrol there is no difference on the xaml side, you will continue to use {StaticResource resourceKey} as when you call a StaticResource it searches though the Resource hierarchy to find the Resource.

So if you move you resource from UserControl.Resources to Window.Resources or Application.Resources you don't need to change anything in your xaml code that is accessing though {StaticResource resourceKey}.

As for access in code behind you will use FindResource("resourceKey") instead of Resources["resourceKey"] as FindResource will search the hierarchy for the Resource like the StaticResource does in xaml.

Example:

m_AnimationHide = (Storyboard)FindResource("AnimationHide");

If you want to modify any of these Resources in a specific control and they are frozen you can just create a copy for that instance

Example

var animation = FindResource("AnimationHide") as Storyboard;

m_AnimationHide = animation.Clone();
m_AnimationHide.Completed += m_AnimationHide_Completed;

You can also set x:Shared="false" this will return a new instance of the animation each time from the Resources, this will save copy/pasting the same animation througout your application if you have a complex Resource that you need to change values in.

<Storyboard x:Key="AnimationHide" x:Shared="false" />

Then you will be able to modify the resource locally.

I did like you said but something is going wrong. I have a piece of code in my UserControl that looks like this: `animation.Completed += handler;`. Whenever I reach that. my application crashes telling me: `DoubleAnimation must have IsFrozen set to false to modify`. Those animations must do something on the UserControl that fired them upon completion. How to fix it? — Tommaso Belluzzo, Mar 23 '13 at 02:32
That because you cant modify the static resource as its frozen, I have added a workaround to my answer — sa_ddam213, Mar 23 '13 at 02:43
Thanks! I tried the first approach (all into App) and it works like a charm. Now I'm trying with the second one (all into MainWindow)... but I'm getting unresolved resource errors whenever I try to reference a MainWindow resource into my custom UserControl. Why? — Tommaso Belluzzo, Mar 23 '13 at 03:39
Because the is no guarantee that the `UserControl` will be placed in that `Window` and have access to its `Resources`, so instead of `{StaticResource resourceKey}` you would use `{DynamicResource resourceKey}`. as this will resolve at runtime. — sa_ddam213, Mar 23 '13 at 04:01
The hierarchy for Resources is: Local object -> Visual Tree up to the Root (the window that hosts the control) -> App Resources. So it should work if you put your control into the main window. If the control is hosted in another window, the resources will not be found. — Roman Gruber, Mar 23 '13 at 04:02

score 1 · Answer 2 · edited May 14 '14 at 20:48

I'd like to expand a bit on the reasoning for moving resources out of the control xaml.

Like you read in the MSDN library, the only technical reason behind moving anything to a higher level is to conserver resources (i.e. memory). Each entry in a ResourceDictionary is created as an object (=instance!) at runtime and takes up memory and the initialization takes a few CPU cycles.

Now the catch with something like the StoryBoard: An object that stores data that is relevant to or even connected to a particular instance of the control - like the instance of the executing animation - has to be created for each instance of the control it should drive. Unless you want all your controls to animate identically and in parallel.

To me it doesn't make much sense to use Clone in code as opposed to just put that thing into the xaml in the first place. The xaml approach takes a bit of copy/paste and thus would mean to modify the animation in more than one place (if you even can re-use something like that across controls) but it will remove the code requirement and still do the same: create an instance of the Storyboard for each instance of the control.

Well it does make sense to `Clone` or use `x:Shared` (xaml version of clone) because if you have a `Themed` application how would you theme that copy/pasted `Resource` easily in multiple places. using either xaml or code clone you only have to change the Resource in the Themed Dictonaries instead of thoughout the entire application. — sa_ddam213, Mar 23 '13 at 04:29

Sharing Application Resources in WPF

2 Answers2