DependencyProperty.Register() or .RegisterAttached()

20,548

Solution 1

I assume you meant DependencyProperty.Register and DependencyProperty.RegisterAttached.

DependencyProperty.Register is used to register normal DependencyProperty. You can see those as just regular properties, with the added twist that they can take part in WPF's DataBinding, animations etc. In fact, they are exposed as normal property (with the get and set accessors) on top of the untyped DependencyObject.SetValue / GetValue. You declare those as part of your type.

Attached properties on the other hand are different. They are meant as an extensibility system. If you have ever used Extenders in Windows Forms, they are kind of similar. You declare them as part of a type, to be used on another type.

They are used a lot for layout-related information. For example, Canvas needs Left/Top coordinates, Grid needs a Row and a Column, DockPanel needs a Dock information etc. It would be a mess if all of this had to be declared on every Control that can be layouted. So they are declared on the corresponding panel, but used on any Control.

You can use the same thing to attach any information to a DependencyObject if you need to. It can come in handy to just declare a piece of information that you can set in xaml just to be used later in a style for an existing class for example.

So those two kind of DependencyProperty serve a very different purpose. Regular properties (registered through Register() ) are used just like normal properties as part of the interface of your type. Attached properties (registered through RegisterAttached() ) are used as an extensibility point on existing classes.

Hope that clarifies it a bit.

Solution 2

The difference between DependencyProperty.Register() and DependencyProperty.RegisterAttached() is that .Register() is used to register a 'regular' dependency property on a DependencyObject, while .RegisterAttached() is used to set an 'attached' dependency property.

The difference between the two types of dependency properties is reasonably straightforward: regular dependency properties are set on a particular DependencyObject just like you would any other .NET property. Attached properties, on the other hand, are associated with a particular DependencyObject (e.g. Grid) but are set on a completely separate DependencyObject, often a child of the DependencyObject that defines the attached property (e.g. Grid.Row, an attached property, is set on the children of a parent Grid).

More details on attached properties are on MSDN.

Solution 3

A property registered with either Register or RegisterAttached can be attached to any DependencyObject with SetValue and GetValue. But if you attach a property registered with Register to an object of type other than the ownerType, its metadata will not be used (except for a default value). It means that attributes such as Inherits or AffectsMeasure will not work for these properties. You should use RegisterAttached if you are interested in metadata on attached properties.

For details, see my answer to a similar question: Difference between Attached and non-Attached Dependency Properties in Silverlight

Share:
20,548
Sander Rijken
Author by

Sander Rijken

I'm a software engineer working with C# at a Dutch software development company. I am also involved in development of the AnkhSvn project, which provides Subversion integration into Visual Studio http://twitter.com/SRijken

Updated on July 09, 2022

Comments

  • Sander Rijken
    Sander Rijken almost 2 years

    What's the difference between the two, when should RegisterAttached() be used instead of .Register()?

  • Ali Mst
    Ali Mst about 14 years
    So attach can be used to add properties to classes that you don't own? Is that the difference?
  • Erusso87
    Erusso87 almost 10 years
    You can set dependency properties that are not attached properties on other object too: this.button.SetValue(TextBox.TextProperty, "text"); (where this.button is of type System.Windows.Controls.Button). This is perfectly fine so the answer is not quite complete. There must be more to it.