Search

With this blog post, Dan Wahlin tries to give some clarity around the concept of dependency properties in Silverlight.

Source: Dan Wahlin's WebLog

I have the opportunity to teach a lot of people about Silverlight (among other technologies) and one of the topics that definitely confuses people initially is the concept of dependency properties. I confess that when I first heard about them my initial thought was “Why do we need a specialized type of property?” While you can certainly use standard CLR properties in Silverlight applications, Silverlight relies heavily on dependency properties for just about everything it does behind the scenes. In fact, dependency properties are an essential part of the data binding, template, style and animation functionality available in Silverlight. They simply back standard CLR properties. In this post I wanted to put together a (hopefully) simple explanation of dependency properties and why you should care about them if you’re currently working with Silverlight or looking to move to it.

Arik Poznanski discusses dependency property value resolution and gives an example to make it clearer.

Source: Arik Poznanski's Blog

One of the strength points for WPF is the ability to set a property value using a wide range of methods.

Unfortunately, this variety makes it hard to understand how a WPF dependency property gets its final value. Hopefully this post will help organize this issue.

In his previous post, Marlon Grech explained how Silverlight 4 lacks the UpdateSourceTrigger for PropertyChanged and how to overcome this issue for the TextBox. In this post he shows how to do this for any Dependency Property of any Framework element.

Source: C# Disciples

Please note that this post is quite an experimental one. Probably the use case you are looking for is for the textbox scenario, if that is the case I would suggest that you use the more explicit approach i.e the one I show in my previous post. The take away from this post should be more the idea of how things work rather than the actual code I am using here, this code was never tested in production thus it might contain memory leaks and other issues.

This is quite easy in WPF. But Silverlight has a limited set of meta-data functionality around the dependency property system, because the DependencyPropertyDescriptor does exist in Silverlight. In order to get a workaround Beat Kiener found a solution in which he gets notified with help of the binding system.

Source: Kiener's Blog

Source: ScottLogic

This article is part 3 of 4 in a series covering everything that I think is worth knowing about styles in Silverlight. The previous parts of the series are Styles in Silverlight: an Introduction and Styles in Silverlight – Inheritance, Precedence and Other Advanced Topics.

Well the biggest issue is that if you want to animate properties of a custom control of some kind using data binding and what that change to filter into the UI of some control. Otherwise I try to avoid DP's as much as possible. 

My last tip outlined the best way I knew to approximate a WPF-like read-only DependencyProperty on Silverlight. (Aside: It's also a good way to implement coercion.) However, it suffers from the unavoidable problem that the actual DependencyProperty is still writable and can "twitch" if written to. The comments for that post proved to be very interesting - with two suggestions for alternate techniques.

The last two tips explained how to set the default value of a Silverlight/WPF DependencyProperty. But there's something you need to be aware of when you're using either technique: the default value of a DependencyProperty is shared by all instances of a class. This doesn't tend to matter for value types, immutable reference types, and sharable types (like brushes), but it affects mutable reference types and can lead to unexpected behavior.

Initializing variables in an object's constructor is considered a Good Thing. Traditionally, initialization is done with a simple assignment that sets the variable to its initial value: MyProperty = 10;. However, doing that with a Silverlight/WPF DependencyProperty uses the CLR wrapper (more background here and here) and results in a call to SetValue that sets the local value of that property.