Bug 22720 - Add support for TargetNullValue and FallbackValue in XAML bindings
Summary: Add support for TargetNullValue and FallbackValue in XAML bindings
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 1.2.2
Hardware: All All
: Normal enhancement
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2014-09-06 12:15 UTC by Jérémie Di Prizio
Modified: 2018-02-12 18:14 UTC (History)
16 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Jérémie Di Prizio 2014-09-06 12:15:11 UTC
At the moment, using either TargetNullValue or FallbackValue in a XAML binding raises a TargetInvocationException which leads me to believe that neither of these properties are implemented (seems to be confirmed by your API reference).

Would be great if they were implemented as setting those fallback/replacement values in the view model code is a bit noisy.

For reference here are the MSDN pages of those properties:

TargetNullValue: http://msdn.microsoft.com/en-us/library/system.windows.data.bindingbase.targetnullvalue(v=vs.110).aspx
FallbackValue: http://msdn.microsoft.com/en-us/library/system.windows.data.bindingbase.fallbackvalue(v=vs.110).aspx
Comment 1 Arpit Jha 2014-09-08 05:53:21 UTC
I have checked this issue with some XAML binding and unable to reproduce it.

Could you please provide us sample project/Steps to reproduce ,build and Environment info also ,So that i can able to check at our end.
Comment 2 Bojan Panjevic 2014-12-11 00:08:31 UTC
I'm also able to confirm the issue. Here is a part of the XAML

 <DataTemplate x:Key="ProfileItemTemplate">
            <StackLayout Orientation="Vertical" Padding="10,0,10,0" HorizontalOptions="Fill">
              <Label Text="{Binding Description}" Font="Large" HorizontalOptions="Fill"/>
              <StackLayout Orientation="Horizontal" HorizontalOptions="EndAndExpand">
                <Entry Text="{Binding Text}" VerticalOptions="Center" WidthRequest="350"
                       IsVisible="{Binding IsTextRequired}" />
                <Switch VerticalOptions="Center"
                  IsVisible="{Binding IsTextRequired, Converter={StaticResource InvertBooleanConverter }}"
                  IsToggled="{Binding IsChecked, TargetNullValue=False}}"/>
Comment 3 Olivier Ansquer 2016-01-22 20:15:09 UTC
These properties are important and it should not be difficult to add. Why so long? Do you have a simple alternative solution?
Comment 4 Jason Smith [MSFT] 2016-03-16 12:34:42 UTC
The request got set to NEEDS INFO somehow (looks like the triager got confused) and the feature request never made it to the dev team. Im digging through the backlog now trying to find everything and just ran across this.

Its now added to the feature board.
Comment 5 Sascha Schwegelbauer 2016-10-02 13:20:06 UTC

-> It's not present in current
Comment 6 Jason Smith [MSFT] 2017-02-14 19:40:19 UTC
This is not on our current roadmap.
Comment 7 JeremyH 2017-02-14 20:19:35 UTC
So after almost 3 years, for such a basic feature:

1. "triager got confused, Its now added to the feature board."

2. "This is not on our current roadmap"

I honestly haven't experienced any library vendor worse than Xamarin.
Comment 8 Olivier Ansquer 2017-02-15 08:12:57 UTC
+1 for JeremyH's answer. This type of response is incomprehensible on such a simple evolution.
Comment 9 zabrucewayne 2017-05-23 14:32:13 UTC
This would be very useful, please consider adding to the backlog.
Comment 10 dstefanov 2017-11-19 03:35:08 UTC
Fallback binding value is indeed very important feature! 
Simple example is: I have IsVisible attribute bind to the BindingContext.IsBuzy where Binding property is set to a ViewModel with property IsBuzy.
By default IsBuzy is false and the control would be hidden. However, what happens when the ViewModel is not set to the BindingContext and the BindingContext is null? The binding fails to find object and property to bind to. When this happens the DefaultValue of property IsVisible is used - True. Now the control would be visible when there is no binding context and by default we want it to be hidden.
If there was a Fallback value we could set it to False for such scenarios where we can't control the BindingContext.
Notice that this is very distinct scenario and is also very common since this is the recommended way to use the BindingContext.
Comment 11 Samantha Houts [MSFT] 2018-02-12 18:14:44 UTC
Migrated to https://github.com/xamarin/Xamarin.Forms/issues/1803. Please follow that issue for updates. Thanks.