When you define a custom XAML dependency property, one of the things you do is specify the default value. You can do this by providing the default value directly:<\/p>\n
DependencyProperty.Register(\"MyProperty\",\r\n propertyType, ownerType,\r\n new PropertyMetadata(defaultValue));\r\n<\/pre>\nUWP XAML also lets you provide a callback that produces the default value:<\/p>\n
DependencyProperty.Register(\"MyProperty\",\r\n propertyType, ownerType,\r\n PropertyMetadata.Create(createDefaultValue));\r\n<\/pre>\nWhat’s not entirely obvious is that the default value statically provided at registration or provided dynamically at runtime should be an immutable object, if you know what’s good for you.<\/p>\n
The default value of a dependency property is the value used if no value has been set: Nobody has explicitly assigned a value, there is no active binding, no active animation, no active style, nothing.<\/p>\n
When XAML needs the default value of the dependency property, it uses the static default property, if provided. Otherwise, it calls the
create\u00adDefault\u00adValue<\/code> delegate, if provided. Otherwise, it usesnull<\/code>.<\/p>\nFor concreteness, let’s say that we have a
Widget<\/code> object and a dependency property of typeLight<\/code>.<\/p>\nLet’s first look at the case where you provide a static mutable value for the default value of the dependency property.<\/p>\n
\/\/ Code in italics is wrong.\r\nclass Light\r\n{\r\n public Color Color { get; set; }; \/\/ read-write property\r\n}\r\n\r\nclass Widget\r\n{\r\n ...\r\n\r\n public Widget()\r\n {\r\n InitializeComponent();\r\n }\r\n\r\n \/\/ The default is a red light.\r\n public static readonly DependencyProperty FrontLightProperty =\r\n DependencyProperty.Register(\"FrontLight\",\r\n typeof(Light), typeof(Widget),\r\n new PropertyMetadata(new Light { Color = Color.Red })<\/i>);\r\n\r\n \/\/ Provide convenient access to the dependency property.\r\n public Light FrontLight {\r\n get => (Light)GetValue(FrontLightProperty);\r\n set => SetValue(FrontLightProperty, value);\r\n }\r\n}\r\n\r\nvoid Example()\r\n{\r\n var a = new Widget();\r\n var b = new Widget();\r\n\r\n var aColor = a.FrontLight.Color; \/\/ aColor is Red\r\n var bColor = b.FrontLight.Color; \/\/ bColor is Red\r\n\r\n a.FrontLight.Color = Color.Blue;\r\n var bColor2 = b.FrontLight.Color; \/\/ bColor2 is Blue (!)\r\n}\r\n<\/pre>\nSince no custom value of
Front\u00adLight<\/code> has been set,a<\/code>.FrontLight<\/code> andb<\/code>.FrontLight<\/code> both contain the default value, which is the redLight<\/code> provided to theProperty\u00adMetadata<\/code> constructor.<\/p>\nBut since
Light<\/code> objects are mutable, the properties of that default value can be changed, and those changes are visible to botha<\/code> andb<\/code>, becausea<\/code>.FrontLight<\/code> andb<\/code>.FrontLight<\/code> are the same object.<\/p>\n“Aha,” you may think, “that’s where the callback version comes in handy.” If you set up the callback to produce a unique object, then
a<\/code>.FrontLight<\/code> andb<\/code>.FrontLight<\/code> will be different objects, and they won’t affect each other.<\/p>\n\/\/ Code in italics is wrong.\r\nclass Widget\r\n{\r\n ...\r\n\r\n public Widget()\r\n {\r\n InitializeComponent();\r\n }\r\n\r\n \/\/ The default is a red light.\r\n public static readonly DependencyProperty FrontLightProperty =\r\n DependencyProperty.Register(\"FrontLight\",\r\n typeof(Light), typeof(Widget),\r\n PropertyMetadata.Create(() => new Light { Color = Color.Red })<\/i><\/span>);\r\n\r\n \/\/ Provide convenient access to the dependency property.\r\n public Light FrontLight {\r\n get => (Light)GetValue(FrontLightProperty);\r\n set => SetValue(FrontLightProperty, value);\r\n }\r\n}\r\n\r\nvoid Example()\r\n{\r\n var aColor = a.FrontLight.Color; \/\/ aColor is Red\r\n var bColor = b.FrontLight.Color; \/\/ bColor is Red\r\n\r\n a.FrontLight.Color = Color.Blue;\r\n var bColor2 = b.FrontLight.Color; \/\/ bColor2 is Red\r\n\r\n var aColor2 = a.FrontLight.Color; \/\/ aColor2 is Red (!)\r\n\r\n if (a.FrontLight != a.FrontLight) TheWorldHasGoneMad(); \/\/ executes!\r\n}\r\n<\/pre>\nThis time, we have the callback create a brand new red
Light<\/code>. When we evaluatea<\/code>.FrontLight<\/code>.Color<\/code>, the first thing that XAML needs to do is obtain the value ofa<\/code>.FrontLight<\/code>, and since nobody has set a value, XAML asks the callback to produce the default. The callback creates a fresh redLight<\/code> and returns it, and that brand new light is the value of thea<\/code>.FrontLight<\/code> property. TheExample<\/code> function reads the color and getsRed<\/code>.<\/p>\nThe same thing happens when you read the color from
b<\/code>.FrontLight<\/code>.Color<\/code>.<\/p>\nSo far so good. The
a<\/code> andb<\/code> objects each have separateFrontLight<\/code> lights.<\/p>\nOkay, now things get interesting: When we try to change the color of
a<\/code>‘sFront\u00adLight<\/code> toBlue<\/code>, the assignment succeeds, and it doesn’t affect the color ofb<\/code>‘sFront\u00adLight<\/code>, but when we try to read the color ofa<\/code>‘sFront\u00adLight<\/code>, we getRed<\/code> again. What happened?<\/p>\nIn the assignment
a<\/code>.FrontLight<\/code>.Color = Color<\/code>.Blue<\/code>, the first thing that happens is the fetch of theFrontLight<\/code> property of thea<\/code> object. And since we still<\/i> haven’t set a value for theFrontLight<\/code> property, XAML uses the default value. And XAML does that by calling the callback, and the callback creates a brand newLight<\/code>. Until a value for theFrontLight<\/code> property is set, every attempt to read theFrontLight<\/code> property will produce a new redLight<\/code><\/i>. In other words, the default value is not cached. XAML calls the callback each time it needs the default value.<\/p>\nThe code sets the color of this brand new light to
Blue<\/code>. But that brand new light isn’t being saved anywhere. It doesn’t become the value of theFrontLight<\/code> property. It ends up orphaned, waiting for the next GC to clean it up.<\/p>\nLater, you read
a<\/code>.FrontLight<\/code>.Color<\/code>. Again, the first step is to retrieve theFrontLight<\/code> property froma<\/code>, and since no value has been set yet, XAML asks the callback to produce the default value, and the callback creates a brand new redLight<\/code>. Every fetch of theFrontLight<\/code> property produces a brand new redLight<\/code>.<\/p>\nThis also explains why the final statement reports that the world has gone mad: The two reads of the
FrontLight<\/code> property each produced a different redLight<\/code>.<\/p>\nProducing a brand new object in response to the default value callback is a bad idea.<\/p>\n
The intended purpose of the callback is to let you have a default value that is itself a dependency object. Since dependency objects have thread affinity, you cannot use the same object for all callers, because the callers may come from different threads. The callback lets you look in some per-thread storage to obtain the correct object for that thread. In the worst case, you can have your own private cache of objects indexed by thread.\u00b9<\/p>\n
Okay, but what if the dependency property’s type is a mutable type. One solution is to make
null<\/code> the default value of the property. As immutable things go,null<\/code> looks quite immutable. Everybody who wants to change theFrontLight<\/code> color must first provide aFrontLight<\/code>. But what if you want the default value to be non-null? We’ll look at this next time<\/a>.<\/p>\n