Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Wpf merged resource dictionary no being recognized from app.xaml

Tags:

I have a WPF .net 4.5 application where I am having trouble merging resource dictionaries.

I have the exact same problem as This SO question and This Question but the accepted solution does not work for me.

I have a resource dictionaries declared in my app.xaml as follows (simplified for clarity):

<Application.Resources>         <ResourceDictionary.MergedDictionaries>             <ResourceDictionary Source="Skin/ResourceLibrary.xaml" />                           <ResourceDictionary Source="Skin/Brushes/ColorStyles.xaml" />                        </ResourceDictionary.MergedDictionaries>     </ResourceDictionary>                </Application.Resources> 

Problem: The app can "SEE" the ColorStyles dictonary when listed in app.xaml, but if I move/nest it inside the ResourceLibrary.xaml, then the ColorStyles.xaml are not "seen" by the app and errors about missing static resources appear.

Here is how I create the ResourceLibrary.xaml dictionary (simplified):

<ResourceDictionary      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">      <ResourceDictionary.MergedDictionaries>          <!--  BRUSHES AND COLORS  -->         <ResourceDictionary Source="Brushes/ColorStyles.xaml" />      </ResourceDictionary.MergedDictionaries> </ResourceDictionary> 

Reason for change: My current organization of my resource dictionaries is awful and I need to change it (as I am creating objects more than once). I wanted to have one resource dictionary in a "Skin" folder and then sub-folders for organizing the remaining style dictionaries which would all be merged in the ResourceLibrary.xaml file which in turn would be called in app.xaml.

What I tried: Yes I did try to use the solution from the link above:

<Application.Resources>     <ResourceDictionary>         <ResourceDictionary.MergedDictionaries>             <ResourceDictionary Source="Skin/ResourceLibrary.xaml"/>         </ResourceDictionary.MergedDictionaries>         <!-- Dummy Style, anything you won't use goes -->         <Style TargetType="{x:Type Rectangle}" />     </ResourceDictionary> </Application.Resources> 

but I get the following error on the dummy style line:

Error 2 Property elements cannot be in the middle of an element's content. They must be before or after the content.

Changing the code to the following got rid of the error above, thanks to lisp comment:

<Application.Resources>     <ResourceDictionary>         <!--Global View Model Locator-->         <vm:ViewModelLocator x:Key="Locator" d:IsDataSource="True" />          <!-- Dummy Style, anything you won't use goes -->         <Style TargetType="{x:Type Rectangle}" />          <ResourceDictionary.MergedDictionaries>             <ResourceDictionary Source="Skin/ResourceLibrary.xaml"></ResourceDictionary>                          <ResourceDictionary Source="Skin/Brushes/ColorStyles.xaml" />             <ResourceDictionary Source="Skin/NamedStyles/AlertStyles.xaml" />          </ResourceDictionary.MergedDictionaries>     </ResourceDictionary>                </Application.Resources> 

but the Resource Library is still not being called.

I also tried to change all the file paths to pack URI's, but that did not solve the problem either.

I tried moving the resourceLibrary.xaml and the other resource dictionaries into a different class library project (using the same folder structure and files as above). I then used the following URI but I still am not able to access resources declared in the ResourceLibrary.xaml file.

<ResourceDictionary Source="pack://application:,,,/FTC.Style;component/ResourceLibrary.xaml" /> 

But again, if I add each resource dictionary to the App.Xaml file, using the UIR format above, the resources are usable.

The error is gone, but I am still unable to use resources that are a part of the merged dictionary in the ResourceLibrary.xaml file. I am inclined to agree with the comment of dowhilefor as to whether or not I should use this approach, but I want to figure this out because the most common solution to this problem (see links at top of this post) is not working and maybe this solution could help someone else.

Question: Why is the ResourceLibrary.xaml file being ignored?

like image 235
J King Avatar asked Jun 12 '13 04:06

J King


People also ask

How to add resource dictionary in app XAML?

Tip You can create a resource dictionary file in Microsoft Visual Studio by using the Add > New Item… > Resource Dictionary option from the Project menu. Here, you define a resource dictionary in a separate XAML file called Dictionary1.

What is merged dictionary in WPF?

Windows Presentation Foundation (WPF) resources support a merged resource dictionary feature. This feature provides a way to define the resources portion of a WPF application outside of the compiled XAML application.

What is ResourceDictionary?

A resource dictionary is a repository for XAML resources, such as styles, that your app uses. You define the resources in XAML and can then retrieve them in XAML using the {StaticResource} markup extension and {ThemeResource} markup extension s. You can also access resources with code, but that is less common.


1 Answers

I hava a big problem with MergedDictionaries and I believe that your problem is the same. I want my ResourceDictionaries to be properly organized, which means for me that there are for example seperate Buttons.xaml, TextBoxes.xaml, Colors.xaml and so on. I merge them in Theme.xaml, often all the Styles are in a seperate assembly (so that I could easily switch Themes). My ApplicationResources are as follows:

<Application.Resources>   <ResourceDictionary>     <ResourceDictionary.MergedDictionaries>       <ResourceDictionary Source="/DefaultTheme;component/Theme.xaml" />     </ResourceDictionary.MergedDictionaries>     <Style TargetType="{x:Type Ellipse}"/>   </ResourceDictionary> </Application.Resources> 

And every StaticResource in the .xamls defined in the main application assembly work, default styles work thanks to the dummy Style. What doesn't work are StaticResources between .xamls inside of Theme. If I define a Style in Buttons.xaml that uses a StaticResource from Colors.xaml, I get an error about StaticResources and UnsetValue. It works if I add Colors.xaml to Application MergedDictionaries.

Solution 0

Abandon organization. Put everything in one .xaml. I believe that is how the ResourceDictionaries were generally supposed to be used because of all the 'problems' with MergedDictionaries (for me this would be a nightmare).

Solution 1

Change all cross-xaml StaticResource references inside of theme to DynamicResource. It works but comes with a price as DynamicResources are 'heavier' than StaticResources.

Solution 2

In every Theme .xaml that uses StaticResources from another .xaml, add this another ResourceDictionary to MergedDictionaries. That means that Buttons.xaml, TextBoxes.xaml and others would have Colors.xaml in their MergedDictionaries. It will result in Colors ResourceDictionary being stored in memory in multiple copies. To avoid that you might want to look into SharedResourceDictionary.

Solution 3

By different ResourceDictionaries setup, different nestings I came up with a theory:

If a StaticResource isn't found above in the same .xaml or in the MergedDictionaries of this ResourceDictionary, it is searched in other top-level MergedDictionaries.

I would prefer to add to ApplicationResources only one .xaml, but I usually end up using two. You dont have to add to ApplicationResources every .xaml that you have in Theme, just - for example - Controls.xaml (with any kind of MergedDictionaries nesting, but no cross-references between Dictionaries of Controls.xaml are allowed) and Common.xaml which contains all common Resources of Controls. In case of Common.xaml nesting is also allowed, but no cross-references, there cannot be seperate Colors.xaml and Brushes.xaml that uses Colors as StaticResources - then you would have to have 3 .xamls added to Application MergedDictionaries.

Now I always use the third solution, but I don't consider it perfect and still would like to know if there is a better way. I hope I correctly interpreted what you described as the same problem as mine.

like image 93
lisp Avatar answered Oct 05 '22 09:10

lisp