views:

179

answers:

3

Dependency properties are created the same way as properties.

Is a dependency property used only while creating a custom control?

+1  A: 

Dependency property is a property (not him self , but depndent on another , let’z say XAML Binding property) which register another property.

The dependecy property register the other binding property in the code behind by registering it . A example that is used in my project is as follows:

public static DependencyProperty ImageUri = DependencyProperty.Register("Source", typeof(BitmapImage), typeof(CustomImagePlaceHolder), new PropertyMetadata(null));

In the above code the ImageUri, is a dependency property which register the Source ,that is defined/declared inside generic.xaml(whatever not sure whether declared , defined or anything else) as follows:

..HorizontalAlignment="Center"
VerticalAlignment="Center"
Height="{TemplateBinding Height}"
Width="{TemplateBinding Width}"
/>

So here it is quite important that the template binding value in the XAML should be registered as dependency property in the code behind.

So when we have defined in XAML that the Image Source should be template bind with Source, we have registered the same Source As a DependencyProperty.

We have to say which type of dependency property is that , in above example the Source is the type of BitmapImage, so we have defined typeof(BitmapImage).

Now the owner/parent of this dependency property is our customControlClass CustomImagePlaceHolder, and we have defined that again while registering.

Now to set the value of depndency property , by using our properties as below:

public BitmapImage Source
        {
            get
            {

   string strURI = (string)GetValue(CustomImagePlaceHolder.ImageUri);
                return new BitmapImage(new Uri(strURI));
            }
            set
{
SetValue(CustomImagePlaceHolder.ImageUri, value);
 }

        }

Now this is how it go, we set the value from our code behind or xaml to the source property defined above , and inturn it sets the value of the dependecy property ImageUri, which inturn sets the value in the template binding Source, as we have registered ImageUri as Source ,that is presennt generic.xaml.

For more Silverlight related concepts have a look at my Blog.

Subhen
+3  A: 

Advantages of Dependency Property

As a matter of fact a Dependency Property have a lots of advantages over the normal CLR properties.

  1. Property Value Inheritance : By Property Value Inheritance we mean that value of a Dependency property can be overridden in the hierarchy in such a way that the value with highest precedence will be set ultimately.
  2. Data Validation : We can impose Data Validation to be triggered automatically whenever the property value is modified.
  3. Participation in Animation : Dependency property can animate. WPF animation has lots of capabilities to change value at an interval. Defining a dependency property, you can eventually support Animation for that property.
  4. Participation in Styles : Styles are elements that defines the control. We can use Style Setters on Dependency property.
  5. Participation in Templates : Templates are elements that defines the overall structure of the element. By defining Dependency property, we can use it in templates.
  6. DataBinding : As each of the Dependency property itself invokes INotifyPropertyChanged whenever the value of the property is modified, DataBinding is supported internally. To read more about INotifyPropertyChanged, please read.
  7. CallBacks : You can have callbacks to a dependency property, so that whenever a property is changed, a callback is raised.
  8. Resources: A Dependency property can take a Resource. So in XAML, you can define a Resource for the definition of a Dependency property.
  9. Metadata overrides : You can define certain behavior of a dependency property using PropertyMetaData. Thus overriding a metadata form a derived property will not require you to redefine or reimplementing the whole property definition.
  10. Designer Support : A dependency property gets support from Visual Studio Designer. You can see all the dependency properties of a control listed in the Property Window of the Designer.

In these, some of the features are only supported by Dependency Property. Animation, Styles, Templates, Property value Inheritance etc could only be participated using Dependency property. If you use CLR property instead in such cases, the compiler will generate error.

pls go throught this article

http://www.codeproject.com/KB/WPF/BeginWPF4.aspx#diff

and http://www.dotnetfunda.com/articles/article961-wpf-tutorial--dependency-property-.aspx

and http://msdn.microsoft.com/en-us/library/cc221408(VS.95).aspx

Kishore Kumar
A lot of those "advantages" are debatable. For example, an standard property can run code to validate the value being assigned. The bottom line is Dependency Properties do two key things, support binding and allow animation.
AnthonyWJones
+7  A: 

Dependency properties and standard properties are quite different.

The key features delivered by dependency properties are support for binding and animation. If you want to assign a value to a property using a Binding or template binding that property needs to be a dependency property. When animating a property the a dependency property can track both the current assigned value and the current animated value.

One other advantage that is often overlooked is that storage is only needed for properties that have values assigned. A typical control can have a lot of properties but its rare code that assigns a new value to all the properties, in fact, most of the properties are left at their default value and only few are actually set. With dependency properties the default values are stored as meta-data related to the property and do not require any memory allocated per control instance if the property remains unassigned.

Dependency properties are not limited to controls (anything derived from DependencyObject can have then) however it is on controls or at least FrameworkElements where they are most useful.

AnthonyWJones
+1: This gets my vote as *it actually answers the question asked*!
Enough already