Bug 23730 - [All platforms] Explicitly setting a property un-sets the SetBinding() binding for that property
Summary: [All platforms] Explicitly setting a property un-sets the SetBinding() bindin...
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 1.2.3
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2014-10-09 22:42 UTC by Cody Beyer (MSFT)
Modified: 2014-10-24 07:59 UTC (History)
7 users (show)

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

TestCase (58.40 KB, application/x-7z-compressed)
2014-10-09 22:42 UTC, Cody Beyer (MSFT)
Simpler test case (92.01 KB, application/zip)
2014-10-13 15:49 UTC, Brendan Zagaeski (Xamarin Team, assistant)

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 Cody Beyer (MSFT) 2014-10-09 22:42:19 UTC
Created attachment 8371 [details]

TestCase: Attached
Video: https://www.dropbox.com/s/0qsg31rrdwjpw50/BugVid.m4v?dl=0

1. Open attached project
2. Build and Deploy to Simulator
3. Enter the "Buy Pears" item
4. Activate Switch
5. Navigate to and Enter Buy Pears
6. Enter some text
7. Disable the switch

Expected Results:
The edited/entered control should become disabled and dark grey

Actual Results:
It stays white
Comment 1 Parmendra Kumar 2014-10-13 05:47:53 UTC
I have checked this issue as per steps defined in bug description, And I am getting same behavior defined in bug description.

IDE Log:https://gist.github.com/Parmendrak/170d68d32663f2e1a828
Output Log: https://gist.github.com/Parmendrak/35e64405c8b2beaf3b9b

Environment Info:
=== Xamarin Studio ===

Version 5.5 (build 227)
Installation UUID: 1a096c6f-0678-402e-89b2-a2c10f7e80e4
	Mono 3.10.0 ((detached/47db868)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 310000019

=== Apple Developer Tools ===

Xcode 6.0.1 (6528)
Build 6A317

=== Xamarin.iOS ===

Version: (Business Edition)
Hash: 959c1e4
Build date: 2014-10-03 00:25:37-0400

=== Xamarin.Android ===

Version: 4.18.0 (Business Edition)
Android SDK: /Users/360_macmini/Desktop/android-sdk-macosx
	Supported Android versions:
		2.1    (API level 7)
		2.2    (API level 8)
		2.3    (API level 10)
		3.1    (API level 12)
		3.2    (API level 13)
		4.0    (API level 14)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
Java SDK: /usr
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

=== Xamarin.Mac ===

Version: (Business Edition)

=== Build Information ===

Release ID: 505000227
Git revision: 7b721eeec7a2fa4c4f4de0ecd2aed4dc25edac95
Build date: 2014-10-02 15:53:38-04
Xamarin addins: 99ed56b428b31eba1efaace4d82188d6f334e6ca

=== Operating System ===

Mac OS X 10.9.4
Darwin ShrutiMac.local 13.3.0 Darwin Kernel Version 13.3.0
    Tue Jun  3 21:27:35 PDT 2014
    root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64
Comment 2 Brendan Zagaeski (Xamarin Team, assistant) 2014-10-13 13:04:50 UTC
The original description is missing some important context from the Desk case.

The reason this behavior is suspected to be a bug is that all of the items have the same binding for the `BackgroundColorProperty`. Selecting and editing an item in the list is somehow disabling the binding on that item.

## Results

- When the user first navigates into the "Buy Pears" editing view, the background color of the "Buy Pears" item responds to the state of the switch control.

- After the user has changed the text of the "Buy Pears" item to "Buy Apples", the background color of the "Buy Apples" item does _not_ respond to the state of the switch control.

## Additional information

I'll update this bug again in a little bit with:

- Confirmation that the problem occurs on the latest Xamarin.Forms version.

- A note about whether the problem also occurs on Android and Windows Phone. In general, I suspect it would be helpful to specify the list of affected platforms on all Xamarin.Forms bugs.
Comment 4 Brendan Zagaeski (Xamarin Team, assistant) 2014-10-13 15:12:52 UTC
Update: I think this might be an intentional behavior of the Xamarin.Forms binding machinery and not a bug.

## Workaround (or maybe really the correct fix)

Change the following line in `TodoItemPage.OnControlLoseFocus()`:

> ((Entry)sender).BackgroundColor = Xamarin.Forms.Color.White;


> ((Entry)sender).SetBinding(StackLayout.BackgroundColorProperty, new Binding("SelectedBackgroundColor", BindingMode.OneWay));

## Further explanation

Explicitly setting [1] the `BackgroundColor` property in `TodoItemPage.OnControlReceivedFocus()` apparently un-sets the binding. Re-setting the binding allows it to work again as normal.

> [1] ((Entry)currentControl).BackgroundColor = Xamarin.Forms.Color.Lime;

## Version information

Tested on iPhone 4s (iOS 7.1.2), iPhone simulator (iOS 8.0), Android device (Android 4.1.2)


Xamarin (ff146f5240189a2ec6d3c6f75cf3967f79c79a18)
Xamarin.Android (3b7ef0a796e8744972c48034403a6e7cb7ec189e)
Xamarin.iOS (65b2f3a0f52f365b90ac952f0ec2e40fa0b510d4)
Comment 5 Brendan Zagaeski (Xamarin Team, assistant) 2014-10-13 15:49:19 UTC
Created attachment 8394 [details]
Simpler test case

This is probably unnecessary at this point, but here's an even simpler test case that also includes sub-projects for all 3 platforms: iOS, Android, and Windows Phone.

This test case explicitly sets the `BackgroundColor` property on `entryElement2` directly during initialization rather than in the `Focused` and `Unfocused` event handlers.

## Steps to reproduce

1. Run the app on any iOS, Android, or Windows Phone device, emulator, or simulator.

2. Tap the `Switch` element.

## Result

The background of the second `Entry` element does _not_ change to gray when the switch moves to the "off" position.

## Workaround / fix

Uncomment the line in `App.GetMainPage()` after the explicit property set that re-sets the binding:

> entryElement2.SetBinding(StackLayout.BackgroundColorProperty, new Binding("SelectedBackgroundColor", BindingMode.OneWay));
Comment 6 Jason Smith [MSFT] 2014-10-20 21:29:32 UTC
Actually this is how Bindings are supposed to work. If you want to set the property without unsetting your binding, you need to update your ViewModel.

Note there was a bug where sometimes the bindings would get unset when the Entry would update as the user types. This has been resolved.
Comment 7 Doug 2014-10-21 07:37:35 UTC
For my scenario, I have some Entry fields that will have bindings for the background color and some that will not have this binding.  For all Entry fields, I need to change the background color when the control receives focus.  I am performing this logic in a base class with several different views derived from this.  Is there a way to tell if a control has bindings set for the background color property and then save the binding information off before changing the color?  Then reset the binding information when the control loses focus?
Comment 8 Doug 2014-10-24 07:59:13 UTC
I wanted to follow up on my question - is there a way to determine if there is a binding defined for a given property, save that binding information off, and then reassign it?