we have a strange problem with the ReactiveValidationObject here.
We have a view with a textbox bound to a ViewModel property. This
property has the [Required] attribute set so there is a validation
error if the property is empty.
The property is set correctly to a non-empty string and the textbox is
displaying it. Still, the textbox shows a validation error. This
validation error immediatly goes away on further changes of the
textbox content or the ViewModel property, its only a first-time
Our View is a bit special because we first set the viewmodel
properties, after that we switch a DataTemplate in a ContentControl of
the view. I guess this is what surfaces this problem.
We had a debugging session and made the following observations:
- raisePropertyChanged in ReactiveObject first fires the
propertyChangedEvent, then it notifies the Changed Observable.
- The Changed observable is subscribed to in the constructor of
ReactiveValidatedObject, here the validationCache is refreshed.
- When our ViewModel was setting its property the raisePropertyChanged
was fired first. This triggered the View to read the IDataErrorInfo
(string this[string columnName]) in the ReactiveValidatedObject. The
validationCache still had an error set because before we load all the
properties of our ViewModel we clear all the fields first.
- Only after that ReactiveValidatedObject stepped into the anonymous
delegate of this.Changed.Subscribe in his constructor and refreshed
the validation cache.
- We could work aorund the problem with firing another
PropertyChangedEvent after our property is set.
There was already another thread were there was suggested to swap the
order of the raisePropertyChanged firing and the Changed observable
notification in raisePropertyChanged. I guess this also would work in
Wouldn't it be generally better to first fire the "internal" event
(Changed) and then the "external" PropertyChangedEvent (where WPF and
the views bind to)? This would guarantee that WPF sees correct state
of the ValidationInfo in this case.