views:

37

answers:

1

When I start my app I get alot information like this:

System.Windows.Data Information: 10 : Cannot retrieve value using the binding and no valid fallback value exists; using default instead. BindingExpression:Path=Period; DataItem=null; target element is 'TextBlock' (Name=''); target property is 'Text' (type 'String')

System.Windows.Data Information: 10 : Cannot retrieve value using the binding and no valid fallback value exists; using default instead. BindingExpression:Path=DocumentId; DataItem=null; target element is 'TextBlock' (Name=''); target property is 'Text' (type 'String')

Should I care for that output?

A: 

Yes, you should. It is safest to treat binding feedback (information, errors, etc) just like compiler warning and errors. Binding issues tend to slow the execution of the application down since it forces bindings to be re-evaluated, and in my experience, sometimes breaks them to where you need to recreate the binding in code.

The simplest workaround, if you can, is to set the FallbackValue on your binding to a value which can be treated as default. For example, if you have a class which has a "Count" property, but said class can be null at some point in time when your view is created, your binding might look like <TextBlock Text={Binding Count, FallbackValue=0} /> which would display a "0" in the text block, or pass the fallback value to the converter if there is one in use.

Hugo
this seems stupid to me even nearly like determine sort of Referential Integrity in database design. My binding always get data else they show nothing so where is the problem? I have no default value for CurrentCustomer.Name why should there be a default? "Jon doe" would not make sense... so why should my binding fall back? Either there is data or there is not... then it shows nothing. I have about 50 properties showing that information "error" Now I have use my fantasy and think about some crazy stuff to name it? LOL and this => BindingExpression:Path=ValidationErrorTemplate; fallback ???
Lisa
There's nothing that prevents a blank value from being a fallback value. In the case of your example, having an empty string as the fallback value would make sense, rather than using a made up value.
Hugo
ok Hugo but from where do I know what to use as a fallback value? Not knowing that could blow my bindings even worse... than it is now.
Lisa
I can even binding information which is slowing all down about properties I have never heard of and I do not use them at all in my whole visual studio solution...: BindingExpression:Path=CellsPanelHorizontalOffset; BindingExpression:Path=HeadersVisibility;
Lisa