Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Other people have provided explanations of dependency properties. I'll try to provide some context around their design. (It helped me understand why these bizarre creations called dependency properties exist in the first place.) There were a few reasons that the designers of WPF added dependency properties rather than using normal properties...</p> <ol> <li>Being able to add a value for a property which isn't applicable to the current element, but is applicable to its children. For example, setting a font on a container and having it cascade down to any contained text elements.</li> <li>The cost in terms of size for unused properties. Taking the font example above... On a well-designed page only a few elements will have their font modified - likely a few top-level containers. If we stored Font as a regular C# property, each object would need a 32/64-bit pointer to a font object with most of them null or with a default value. Magnify this by the number of XAML properties and the typical number of elements on a page and you end up requiring a huge amount of space for storing nothing or default values. Compare this with dependency properties where values only occupy space if they are set. (I haven't looked at the internal implementation, but I imagine that GetValue(propName) and SetValue(propName) store the values in some sort of per-object/per-propety hashtable.)</li> </ol> <p>It would be nice if Microsoft provided a nicer syntax for creating new dependency properties by hiding away the repetitive code with compiler magic, much as they do for iterators. Maybe in C# 6... :)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload