I'm trying to understand the concept behind coerce and validate.
In DependencyProperty's constructor you can give it ValidateValueCallback.
When registering the DependencyProperty in UIElementData::RegisterProperty<>, I can also add ValidateValueCallback.
Also, in registering, the PropertyMetadata may be created with CoerceValueCallback and PropertyChangedCallback.
My questions:
1. Does ValidateValueCallback in registering overwrite the ValidateValueCallback in DependencyProperty's constructor.
2. What is the reason behind given those three callbacks in different locations.
3. What is the function of each callback:
a. I would expect all of them to be called when ever the DependencyProperty's data is changed (whether from with in the widget like in textbox or when programmatically changed or in any other way through the GUI if it's possible). Am I right?
b. I would expect ValidateValueCallback to be able to prevent the change by returning false. In which case PropertyChangedCallback won't be called at all.
c. I would expect CoerceValueCallback to change the actual value expressed by the DependencyProperty. However, what is the meaning of the return value. Does result of false will be the same as invalidating the value. Or perhaps it has another meaning>
d. In which order those are called?

Thanks

1. Yes, when registering a DP, the ValidateValueCallback passed in the registration is used to construct the DP.

2. ValidateValueCallback is passed to DP construction because it defines what values are valid for the property, and that is defined once. Other classes overriding the DP can't change that. But CoerceValueCallback and PropertyChangedCallback can be overriden by other classes using the DP, to adapt the values to other properties or respond to value changes in their own way. That is why these callbacks are passed in the PropertyMetadata instead.

3. a) Yes, all callbacks are called when a DP is changed, first to verify that the value is valid (using ValidateValueCallback). If that is ok, then value is coerced (using CoerceValueCallback) so the user can restrict the values to some constraints, and finally if value changed the PropertyChangedCallback is executed to notify of that change.

b) Exactly, if ValidateValueCallback returns false the value is not set and an error is produced.

c) The return value of CoerceValueCallback indicates if the value was modified/coerced by the user callback or not. Coerced values have priority over the local value, so if you for example set a value of 100 to a property, and then the coerce callback sets a 50, the effective value you will receive when doing GetValue will be 50.

d) As mentioned aboved: ValidateValueCallback, CoerceValueCallback, PropertyChangedCallback

Hope this helps.

Thanks sfernandez,

Good answer.
Regarding the last answer, the order of execution.
I managed to investigate it a bit better myself.
According to what I see, CoerceValueCallback is executed before ValidateValueCallback.
It's actually reasonable. We would like ValidateValueCallback to validate the final value given by CoerceValueCallback.
CoerceValueCallback could for example capitalize a word while ValidateValueCallback accept only capitalized word.

Thanks

You're right, I was talking from memory :)
The order is Coerce, Validate, PropertyChanged.

Marking this topic as solved then.