The resource-resources of WPF learning

WPF uses resources to preserve styles that can be reused, object definitions, and traditional resources such as binary data, images, and so on, and are more able to demonstrate the superiority of these resource definitions in their support. For example, through the support of ResourceDictionary can be through the resources to achieve the skin-changing function, in the expressionblend design of cool modeling can also be exported into resources to be easily referenced by programmers, localization of the implementation of access to the other assembly embedded resources and so on. These provide us with a wealth of tools to build rich media applications through a resource access architecture. This article briefly explains the classification of the WPF resources and its common usage, and simply touches on using ResourceDictionary to manage multiple resources files (this is the basis for skin change).

Resources in WPF rely not only on core. NET resource systems, but also on their support for two different types of resources: binary resources and logical resources. There are also more support options for building actions on these resource types.

1. Binary Resources

Binary resources are actually some traditional resource items, such as bitmaps, audio files, video files, loose files (Loose file) and so on. For these resource items we can store them as loose files, or compile into assemblies. This is with the traditional. NET programs are actually interlinked, but there are two building options for binary resources in WPF:

· Resource: Place Resources in an assembly (if localized support is compiled into a child assembly of the corresponding language set).

· Content: Add this resource to the assembly as a loose file, and the Assembly records whether the corresponding file exists and its path. This is equivalent to the common build action in our web development.

This is also the default build type for MSBuild, for example,

<content include= "Images\go.ico"/>
<content include= "Images\go.jpg"/>
<content include= "Images\go2.gif"/>
<content include= "Images\go2.jpg"/>
<content include= "Images\information16.png"/>
<content include= "Images\pass16.png"/>
<content include= "Images\pass32.png"/>
<content include= "Images\unknown16.png"/>
<content include= "Images\warning.gif"/>
<content include= "Images\warning16.png"/>
<embeddedresource include= "Loginform.resx" >
<SubType>Designer</SubType>
<DependentUpon>LoginForm.cs</DependentUpon>
</EmbeddedResource>
<embeddedresource include= "Optionsform.resx" >
<SubType>Designer</SubType>
<DependentUpon>OptionsForm.cs</DependentUpon>
</EmbeddedResource>
<embeddedresource include= "Pagehistory.resx" >
<SubType>Designer</SubType>
<DependentUpon>PageHistory.cs</DependentUpon>
</EmbeddedResource>

Shown above is a common project file for a WinForm application, and the default build action for the binary resource file added to its internal is content-to indicate that it is stored as a loose file, You can automatically load a file that guarantees its corresponding path (without having to include it in your packaging file). And you'll also see the EmbeddedResource build action, which is the WinForm build action, similar to the resource build action, which embeds a binary resource in the assembly, but in WPF, because embedded resources have more priority than WPF, you need to avoid using them as much as possible.

The resource and content build types are recommended because such embedded resources can easily be referenced in XAML, and the unified Resource identifier for WPF is designed specifically for both of these build actions. Conversely, the resources embedded in the EmbeddedResource build action cannot be referenced in XAML unless custom code.