Question

Could anyone explain the reasoning behind making say ItemsControl.DisplayMemberPath a dependency property and not just a regular CLR property?

Are there any real life scenarios when such properties are used in data binding scenarios, styles, or other dependency property related situations.

Thanks.

Update:

The reason for this question are statements like

Making your property a dependency
property is not always necessary or
appropriate and will depend on your
needs. Sometimes, the typical
technique of backing your property
with a private field is adequate.

in MSDN documentation which kind of make control developers question declarations of dependency properties which have no clearly identifiable benefits of being a dependency property.with a private field is adequate.

Answer 1

Consistency: As a developer you can’t assume that no one out there would require a particular feature(in a particular case). When I develop any custom control I make sure to make all public properties DP’s as you never know someone using that control/property may have a requirement to bind it or use it in style etc. So it is better to be consistent; as, if some of controls properties support Binding, styling etc. I expect other properties to support them too.

I have faced this issue a lot with 3’rd party controls like Sync-fusion; On numerous occasions we had raised tickets asking for Binding support for various control properties. As mentioned in this question:

Why do so many wpf controls implement CLR properties instead of dependency properties?

There can be a particular reason for having this property as DP but in general I haven’t come across any property(WPF Controls) which is not a DP; and thats really useful, you can design UI(using Binding, styling etc.) without going and checking each and every property of all controls.