[WPF] Mutual reference and merge of multiple resource files and Their Solutions

We all know that WPF All controls have Resources Attribute, which can be placed in Resource . Generally Resource Location is Application Of Resource And various Window Of Resource . Then the two Resource In addition to the different scope, what is the difference?

One difference is that,ApplicationOfResourceWill be applied to a global sharedResource. This will giveMerge resource dictionaryIt brings great convenience, but it is not as easy as imagined.

 

In actual projectsResourceThe use of the following requirements.

1. do not put all resources in one file. We often set resource according to its function or object usage, they are placed in different resource dictionary , which is not only clear in structure, but also easy to find, in addition, you can use blend to enable it faster, and there will be fewer conflicts between common development.

2.UseResourceFor performance considerations, try to useStaticresource. This requirement will be groundedResourceDefined in order, that is, undefinedResourceIs not usable. WhileXAMLSimilarCStatement or header file in the language. This wayResourcePay attention to the order. When you are not carefulNotfindexception.

 

After the preceding two requirements are combined, the problem becomes complicated. BecauseResourcePlaced in differentResourceFile, this must take into accountResourceCross-file reference. There are two solutions to this problem.

1. If resource file A , resource file B in the ""> file A , passed resourcedictionary. mergedresourcedictionaries resource file B is merged. One problem with this method is that you need to maintain a list of dependent files for each file, and if there are multiple resources file merge the same resource files give people a sense of redundancy. Is this resource is there multiple copies of a file?

2.Another way isApplicationOfResourceAllResourceAll filesMergeCome in. And one by oneMerge. In this way, the followingMergedresourceYou can accessMergedresource. And onlyApplicationOfResourceIn this way to write results.

 

MergeresourceThe following is an example. UseCodeIt will be more intuitive.

Merge Resource

< Resourcedictionary >
< Resourcedictionary. mergeddictionaries >
< Resourcedictionary Source = "Commonproperties. XAML" />
< Resourcedictionary Source = "Button. style. XAML" />
< Resourcedictionary Source = "ComboBox. style. XAML" />
</ Resourcedictionary. mergeddictionaries >
</ Resourcedictionary >

 

 

In the preceding example, ifXXXX. style. XAMLInResourceToStaticIs usedCommonproperties. XAMLInResourceAs shown in.

Figure 1.ResourceExample of the reference relationship

 

ThenMergeResourceMethod, can it be guaranteed?XXXX. style. XAMLCan be referencedCommonproperties. XAMLInResourceWhat about it? The answer is not necessarily.MergeresourceWhere is the code stored?App. XAML.

 

As shown in.

Figure2.FeasibleMergeMethod (directly inApplicationOfResourceLiMerge)

Figure3.UnfeasibleMergeMethod. (In a separate fileMerge)

Figure4.Is not feasible (inWindowMediumMerge)

 

Therefore WPF Program, Try App. XAML Proceed Resource Of Merge Work. However, this also causes some problems. For example DLL Encapsulation-dedicated storage Resource Of DLL , Cannot pass an existing Merge Okay, single Resource File DLL All in Resource Exposed to the user, the user must App. XAML One by one DLL All Resource File, DLL Changed, App. XAML And thus damage the encapsulation. Another problem is that WPF Application (For example Winform Program Integration WPF), Then there may be no Application Level Resource , There is no good Merge Resource . There are four feasible solutions.

1.CreateWPF Application, AndHostIn the original programWinform. InsteadWinformProgramHost WPFComponent.

2.Put allResourcePut it in a file and maintain itResourceSo that there is no reference problem between files.

3.For eachResourceAll files are usedMergedresourcedictionary. UsedResourceFileMergeCome in. This solution may causeResourceRepeated issues.

4.Step back. References Between FilesDynamicresource. Some people thinkDynamicresourceRatioStaticresourcePoor performance, I agree. After testing, dynamicresource uses five times the time of staitcresource.However, ifResourceIt will not change, but it will be slower during the first loading. Let's take a look at the performance issues.

 

You can only application merge resource file may be regarded as a bug , because from the perspective of WPF users, always hope that no matter where this merge is, you can ensure that the resource file can be referenced up.