What are the reasons/scenarios for properties like DisplayMemberPath to be dependency properties?

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

DisplayMemberPath is probably rarely defined with a binding, but I can think of scenarios where it would be useful...

For instance, if you want to create a DataGrid where you dynamically control the columns, you might need to bind DisplayMemberPath to some property of your ViewModel.

You could also set it in a style or template trigger to display one member or another depending on some condition.

Answer 2

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:

http://stackoverflow.com/questions/2572101/why-do-so-many-wpf-controls-implement-clr-properties-instead-of-dependency-proper

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.