IValueConverter and Exception Check

I am using a custom DateTimeToString: IValueConverter

In my ConvertBack method, I throw an exception when the conversion fails, however it does not appear as a validation failure (this is an unhandled application exception), and I want to show it as a validation problem (red frame).

In short, I want it to work like DateTime + Texbox when it shows a validation message ("the input line was in some format"), but with my usual IValueConverter.

+6
source share
4 answers

Although I agree with winSharp93 to answer fooobar.com/questions/891108 / ... basically, I found that if you return the ValidationResult from ConvertBack , you will get the expected validation behavior.

You will need to use TryParse or TryParseExact as follows, or catch a FormatException if you are using Parse .

DateTime result; if (DateTime.TryParseExact(dateString, dateFormat, culture, DateTimeStyles.None, out result)) { return result; } else { return new ValidationResult("Date string format error"); } 
+8
source

It just turned out that this is a known ivalueconverter behavior. This is because ivalueConverter is not part of the "validation pipeline" in Silverlight. Since ivalueConverter throws exceptions before it enters the validation logic, it is not considered a validation error. The same issue has a post in the Silverlight forum . Someone started a request in dotnet.uservoice . Personally, I believe that this should be fixed / improved, because the converter is a logical place for a validation error. After all, how often do we get a conversion error? Many!

+3
source

Although using ValueConverters is possible, I would not recommend it.

Take a better look at the MVVM-Pattern (Also see: Thought: MVVM eliminates 99% of the need for ValueConverters ). You can then implement IDataErrorInfo in your ViewModels models, and the verification will be as simple as it is.

Staying with ValueConverts will give you more headaches according to my experience.

+1
source

I had a similar problem when using a value converter and MVVM template. The problem was with setting the value in the data binding model in the model. The binding is fired, and the exchangedevent property is raised. Thus, the value has already been changed, and then the converter received a call.

If you change an event with a changed function, and then call it, it throws an unhandled exception, even if you set ValidatesOnException to true. This is due to the fact that the binding has already been updated as a result of triggering an event with a changed property. The converter then starts and throws an exception, but the control cannot catch it.

I moved the logic from the converter to perform a check in the viewModel binding property adjuster. Only if the data was valid, I had to run NotifyPropertyChangedEvent. Otherwise, I would choose an exception that will be displayed in the user interface using the ValidatesOnException property for the binding.

Hope this helps.

+1
source

Source: https://habr.com/ru/post/891108/


All Articles