WPF Learning (iv)-Additional properties

Calm down one night, I will be the process of learning is watching the dog blood plot of the martial arts fiction: No garbage wushu, only the garbage warrior ...

There is one more thing to say: You are users, not customers, there is a use of power. Make sure of your identity, and don't be too crooked!

There is no way, the whole world is good, I have to learn from goodness.

From a usage point of view, attached properties differ from dependency properties.

The dependency property is defined to satisfy the requirements of binding technology and to achieve the purpose of synchronizing data between objects.

Instead of attaching properties, it is in order to implement other objects that have some of my properties for this purpose.

The first time you see an app with attached properties, it appears in the XAML document.

<Window>
<Grid>
<button x:name = "Btn1" grid.row = "1"/>
</Grid>
</Window>

button, itself does not have the layout relationship properties, the outer grid has some layout relationship properties, button as long as the reference, you can re-position, how magical implementation!

The attached property means that the character I define can be used to modify himself. To put it another way, someone else took my sign and described himself as an additional attribute of his.

Here, the definition of "I" is called the host , "Others" is called the Subscriber , to implement a simple attached property use case.

    classHostobject:dependencyobject { Public Static stringgetattachedtext (DependencyObject obj) {return(string) obj.        GetValue (Attachedtextproperty); }         Public Static voidSetattachedtext (DependencyObject obj,stringvalue) {obj.        SetValue (attachedtextproperty, value); }        //I think this attribute should be called a visa, the registration process is to register         Public Static ReadOnlyDependencyProperty Attachedtextproperty =dependencyproperty.registerattached ("Attachedtext",typeof(string),typeof(Hostobject)); }

Defining the host

    class Order:dependencyobject    {    }

Define Subscribers

         Public Static voidTestattachedproperty () {//a polite usage, from the host access valueOrder A =NewOrder (); Hostobject.setattachedtext (A,"AAAA" );            Console.WriteLine (Hostobject.getattachedtext (a)); //One more time, two objects each accessing their own valuesOrder B =NewOrder (); Hostobject.setattachedtext (b,"bbbb" );        Console.WriteLine (Hostobject.getattachedtext (b)); }

Test Cases

You can see that there is no relationship between the host and the class of the Subscriber.

In terms of performance, the host provides Getattachedtext and Setattachedtext methods that allow subscribers to order their own dedicated registers, which ultimately seem to have some additional attributes. A closer look at the implementation of these two methods, in fact, by the subscribers themselves to invoke the GetValue and SetValue methods, to the purpose of saving/fetching values, rather than the host to do these things.

Learning from the previous one, I have learned that the place where attached properties store values is not in the host, nor in the subscribers, but in a separate container for unified management.

objects that use attached properties require derivation from DependencyObject, so that the GetValue and SetValue methods can be used to access data from the container.

The host gives itself a layer of icing, implements the Getattachedtext and Setattachedtext methods, and displays the attached properties of the Subscriber from the host object.

We can also access additional properties from the Subscriber.

         Public Static void TestAttachedProperty2 ()        {            new  Order ();             " CCCC "  );             string string ) C.getvalue (hostobject.attachedtextproperty);            Console.WriteLine (value);        }

Access value from subscriber

I can be a little more indulgent.

         Public Static voidTestAttachedProperty3 () {DependencyProperty Myattachedvisa= Dependencyproperty.registerattached ("Myattachedregistername",typeof(string),typeof(Simpleclass)); Order D=NewOrder (); D.setvalue (Myattachedvisa,"Hello Myattachedregister" ); stringvalue2 = (string) D.getvalue (Myattachedvisa);        Console.WriteLine (value2); }

accessing data directly from attached properties

It appears that, as long as the class is derived from DependencyObject, its objects can extend the handle to the container.

Think back to the first Magic button and grid, how to implement the layout? Without the static snapshot of the principle, it can be implemented by code.

         PublicWindowtestattachedproperty () {InitializeComponent (); Grid Grid=NewGrid (); Grid. Columndefinitions.add (Newcolumndefinition ()); Grid. Columndefinitions.add (Newcolumndefinition ()); Grid. Columndefinitions.add (Newcolumndefinition ()); Button Button=NewButton (); //you can use the static method of the host to setGrid.setcolumn (Button,1 ); //You can also use the instance method of the subscriber to setbutton. SetValue (Grid.columnproperty,1 ); Grid.            Children.add (button);  This. Content =Grid; }

Code implementation attached property call

That magical phenomenon is realized here: grid. Children.add (button);

The layout object is a good shelf, defining areas for future sub-objects that may come. When each child object is added, it assigns a location to the child object.

This logic is simple, and after the layout object calls the Addchildren method, the attached property-related properties in the sub-object are defined.

These property values can also be obtained by the layout object. It would be nice to use these values to assign a location.

Creating a container that allows both the host and the subscriber to access the data inside is a technique that has been used by WPF as a core technology to showcase many magical phenomena.

The programmer is actually going to give up the original power of structural design and invoke a lot of specious icing, and the programmer does just what it looks like.

Worship it, and you will never know how ordinary it really is. WPF has been implemented with the most idiotic tricks-flexibility and freedom!

Someone gave WPF a nickname-I admire. For me, it took a week, and I finally found out that the technology I was studying was incredibly stupid-I inorder!

WPF Learning (iv)-Additional properties