5.3 KiB
title, ms.date, dev_langs, helpviewer_keywords, ms.assetid
| title | ms.date | dev_langs | helpviewer_keywords | ms.assetid | |||||
|---|---|---|---|---|---|---|---|---|---|
| XAML Loading and Dependency Properties | 03/30/2017 |
|
|
6eea9f4e-45ce-413b-a266-f08238737bf2 |
XAML Loading and Dependency Properties
The current [!INCLUDETLA2#tla_winclient] implementation of its [!INCLUDETLA2#tla_xaml] processor is inherently dependency property aware. The [!INCLUDETLA2#tla_winclient] [!INCLUDETLA2#tla_xaml] processor uses property system methods for dependency properties when loading binary [!INCLUDETLA2#tla_xaml] and processing attributes that are dependency properties. This effectively bypasses the property wrappers. When you implement custom dependency properties, you must account for this behavior and should avoid placing any other code in your property wrapper other than the property system methods xref:System.Windows.DependencyObject.GetValue%2A and xref:System.Windows.DependencyObject.SetValue%2A.
Prerequisites
This topic assumes that you understand dependency properties both as consumer and author and have read Dependency Properties Overview and Custom Dependency Properties. You should also have read XAML in WPF and XAML Syntax In Detail.
The WPF XAML Loader Implementation, and Performance
For implementation reasons, it is computationally less expensive to identify a property as a dependency property and access the property system xref:System.Windows.DependencyObject.SetValue%2A method to set it, rather than using the property wrapper and its setter. This is because a [!INCLUDETLA2#tla_xaml] processor must infer the entire object model of the backing code based only on knowing the type and member relationships that are indicated by the structure of the markup and various strings.
The type is looked up through a combination of xmlns and assembly attributes, but identifying the members, determining which could support being set as an attribute, and resolving what types the property values support would otherwise require extensive reflection using xref:System.Reflection.PropertyInfo. Because dependency properties on a given type are accessible as a storage table through the property system, the [!INCLUDETLA2#tla_winclient] implementation of its [!INCLUDETLA2#tla_xaml] processor uses this table and infers that any given property ABC can be more efficiently set by calling xref:System.Windows.DependencyObject.SetValue%2A on the containing xref:System.Windows.DependencyObject derived type, using the dependency property identifier ABCProperty.
Implications for Custom Dependency Properties
Because the current [!INCLUDETLA2#tla_winclient] implementation of the [!INCLUDETLA2#tla_xaml] processor behavior for property setting bypasses the wrappers entirely, you should not put any additional logic into the set definitions of the wrapper for your custom dependency property. If you put such logic in the set definition, then the logic will not be executed when the property is set in [!INCLUDETLA2#tla_xaml] rather than in code.
Similarly, other aspects of the [!INCLUDETLA2#tla_xaml] processor that obtain property values from [!INCLUDETLA2#tla_xaml] processing also use xref:System.Windows.DependencyObject.GetValue%2A rather than using the wrapper. Therefore, you should also avoid any additional implementation in the get definition beyond the xref:System.Windows.DependencyObject.GetValue%2A call.
The following example is a recommended dependency property definition with wrappers, where the property identifier is stored as a public static readonly field, and the get and set definitions contain no code beyond the necessary property system methods that define the dependency property backing.
[!code-csharpWPFAquariumSln#AGWithWrapper] [!code-vbWPFAquariumSln#AGWithWrapper]