locked
Dependency Property and Attached Property Need Clarifications RRS feed

  • Question

  • So, I've read two books and googled like hell, but i still need more clarifications of how these two concepts work, lets start off with Dependency Property.

     

     

    I know that the typical design is that you have an Initialized static DependencyProperty inside the class type for every property that the class supports, and i know that you can register  additional metadata info for default values and change notification when initializing it, etc. I'm also aware that the class type must directly or indirectly derive from DependencyObject, and in essence the the property value is stored in a sparsed storage form, that's essentially like a hash/dictionary.

     

    Now my question, does that mean everytime the SetValue and GetValue calls are made, the static DependencyProperty which is passed to the method calls, act like a Key value in accessing and setting the value?

     

     

    I was also reading about property triggers, and how say when you have an animation or going on when a property value changes, you can change a button's color from it's original state to blue for example, and then be able to revert back, how does this work? does that mean the DependencyObject's storage mechanism is more confusing than a hash/dictionary, as in, does it retain two hash/dictionary collections, one with current values and one with previous values?

     

    Now to AttachedProperties, this is a puzzle for me, i know it's probably essentially the same, but it calls RegisterAttached, but i need some clarifications, i think i saw some code once where it was like:

     

    <StackPanel TextBlock.Text="sometext">...</StackPanel>

     

    From reading, the code gets converted to

     

    StackPanel s = new StackPanel();

    TextBlock.SetText(s, "sometext");

     

     

    Something like that, now what i don't get is, ok, so first of all the SetText method, is calling it's own DependencyProperty of Text, and does that mean, it's storing the value of "sometext" in an instance of TextBlock, or is it going to do something like:

     

     

    public void SetText(UIElement uie, object value)

    {

    uie.SetValue(TextBlock.TextProperty, value);

    }

     

    Is that what it's doing? So my question is, does attached property values get stored inside the Property source object, OR does it get stored in the child element that's using the attached property?

     

     

    Furthermore since you set the attached property like "TextBlock.Text" inside the element, i know that the compiler essentially calls TextBlock.SetText, what i don't get is, how is it aware that the Text property wrapper is associated with the SetText method?

     

    Going off the above example still, if you're setting the text on a StackPanel, does that the following two XAML block are analogous?

     

     

    <StackPanel TextBlock.Text="sometext">...</StackPanel>

     

     

    <StackPanel TextBlock.Text="sometext">

     

    <TextBlock Text="sometext">

    ...

    </TextBlock>

    </StackPanel>

     

     

    Since the converted procedural code is typically:

     

     

    StackPanel s = new StackPanel();

    TextBlock t = new TextBlock();

     

    t.SetText(s, "sometext");

     

    s.Contents = t;

     

     

     

    Thanks you in advance for everyones help in clarifying my questions.

     

     

    Thursday, June 21, 2007 1:01 AM

Answers

  • > Now my question, does that mean everytime the SetValue and GetValue calls are made, the static DependencyProperty which is passed to the method calls, act like a Key value in accessing and setting the value?

     

    Yes.

     

    > I was also reading about property triggers, and how say when you have an animation or going on when a property value changes, you can change a button's color from it's original state to blue for example, and then be able to revert back, how does this work? does that mean the DependencyObject's storage mechanism is more confusing than a hash/dictionary, as in, does it retain two hash/dictionary collections, one with current values and one with previous values?

     

    Sort of - but not quite.  Rather, we do cache the effective value of the property (if non-default) in the storage, but property triggers don't actually set values, they simply provide - for the duration - a new value.  When we look up values for the property system, we check multiple sources, with an order of precedence, where Animation beats local values which beat Setters which beat inherited values which beat default values, etc (and I'm not certain of that order - this is just for illustration).

     

    >public void SetText(UIElement uie, object value)

    >{

    >uie.SetValue(TextBlock.TextProperty, value);

    >}

     

    >Is that what it's doing?

     

    Yes.

     

    >So my question is, does attached property values get stored inside the Property source object, OR does it get stored in the child element that's using the attached property?

     

    Stored on the "target" object, with the Property as the key, and the value as the value.

     

    >Furthermore since you set the attached property like "TextBlock.Text" inside the element, i know that the compiler essentially calls TextBlock.SetText, what i don't get is, how is it aware that the Text property wrapper is associated with the SetText method?

     

    I believe that it uses reflection, such that FooClass.Bar would cause the compiler to look for a method with the signature of "static void FooClass.SetBar(...)", though you can also always just do "target.SetValue(FooClass.BarProperty, value);" since that must be the implementation of FooClass.SetBar in order to avoid nasty surprise behavior (which would result if you did extra work in SetBar which is bypassed by callers calling SetValue directly).

     

    Hope this helps,

    Thursday, June 21, 2007 6:17 AM