Inconsistent FallbackValue & Converter Usage


It appears to me that the usage of FallbackValue in BindingGeneric is inconsistent. In two of the three places where it is used to set the target property value, the Converter is not used. In third place (GetSourceValue) the Converter is used. This appears to be causing the issue that I am having with a null value in the middle of a source property chain which is bound to a target of a different Type. The test case for this scenario contains a source and target of the same type (string) and so the inconsistency does not cause a failure.

I have solved the problem by changing the Type of the FallbackValue to TTarget and removing the use of the Converter in GetSourceValue. This broke one test, BindingConverter_ConvertInvalidDateConversion_NoError, which looks like it was incorrect to begin with because if the Converter fails (trying to exactly parse the invalid date) the Target should be set to the default DateTime (and the assert compares to reference date).

I understand that this change is a breaking change but for me it opened up a lot of scenarios that previously were throwing exceptions. I tried going down the opposite path of using the Converter in all three places first but it led to (what appeared to be) an unresolvable issue in the case of the Converter throwing an exception...then the FallbackValue should be used but you need to use the Converter...

The Microsoft binding appears (if my research is correct) to expect both the FallbackValue and the TargetNullValue to be of type TTarget and they do not get run through the converter.

Has anyone else run into this? Are there other solutions? Laurent are there any changes coming in the next version related to this? I am glad to share the changes if they are of any interest.

Thanks for the great framework. I absolutely love using it!



Sylapse wrote Jul 14 at 6:32 AM

Yes would be really handy if this was changed. At the moment fallbackValue is only usable if TSource and TTarget are the same type. It also fails if you try to use it with the WhenSourceChanges callback as well.

Being able to bind to complex property chains with potential nulls would be very helpful.