none
Does setting a control property remove any binding?

    Question

  • I've read that setting a control property to a specific value will replace any binding on that property, and I could swear I've run into that being the case.  But, recently, I was quite surprised to find that a case like this appears to work just fine - it sets the value and keeps the binding intact:

    This is in SL 4 - In a view, I've got something like this: (actually in a UserControl inside a view) (DataContext is my VM)

                    <CheckBox Name="checkBox1"
                              Content="Check Me"
                              IsChecked="{Binding MyBool, Mode=TwoWay}" />
    

    In the codebehind for the UserControl, we have something like this:

    checkBox1.IsChecked = true;

    I would have expected that this would erase the binding, but it seems to carry on just fine.

    Are there some cases where setting a property directly in code will undo a binding?

    Maybe I'm just having flashbacks of fighting with ComboBox's SelectedValue issues...

    Thanks,

    Dave

    Thursday, November 17, 2011 12:56 AM

Answers

  • Maybe now I understand your point. For example you can set in XAML Text property to some expression involving Binding. When you now set in your code Text to some local string - what happens? I bet your binding set in XAML is eliminated.

                var be1 = textBox1.GetBindingExpression(TextBox.TextProperty);
                textBox1.Text = "LoLO";
                var be2 = textBox1.GetBindingExpression(TextBox.TextProperty);
               // here be2 is null
    
    Monday, November 21, 2011 11:19 AM

All replies

  • What you have read is wrong. Setting value directly coresponds to some user interaction, more or less. Has no influence on binding.

    Regards, Greg

    Thursday, November 17, 2011 2:31 AM
  • Hi,

    That doesn't clear any binding. Because we use clearbing class for that.

    Thursday, November 17, 2011 2:39 AM
  • So just to make sure...this quip should go on the stack of MSDN Silverlight stuff that isn't quite right, or is there some difference I'm missing?

     Bindings are treated as a local value for purposes of dependency property value precedence, which means that if you set another local value, you will eliminate the binding.

    Pasted from <http://msdn.microsoft.com/en-us/library/cc221408(v=VS.95).aspx>

     

     

    Thanks,

     

    Dave

    Thursday, November 17, 2011 8:17 PM
  • Maybe I'm missing something, but I think the key is that you have a two-way binding.  Being able to set a value from the target control is really the whole purpose of a two-way binding.

    If you change it to a one-way binding and then set the value, I think you'll see the behavior that you expected.  MSDN says "eliminate", but honestly I usually think of it as "breaking the binding", because when this happens it's usually not what I intended.

    Friday, November 18, 2011 2:21 PM
  • Maybe now I understand your point. For example you can set in XAML Text property to some expression involving Binding. When you now set in your code Text to some local string - what happens? I bet your binding set in XAML is eliminated.

                var be1 = textBox1.GetBindingExpression(TextBox.TextProperty);
                textBox1.Text = "LoLO";
                var be2 = textBox1.GetBindingExpression(TextBox.TextProperty);
               // here be2 is null
    
    Monday, November 21, 2011 11:19 AM
  • I would have expected that this would erase the binding, but it seems to carry on just fine.

    Hi Dave,

    of course it erases the binding:

                var ce1 = checkBox1.GetBindingExpression(CheckBox.IsCheckedProperty);
                // ce1 is NOT null
                checkBox1.IsChecked = false;
                var ce2 = checkBox1.GetBindingExpression(CheckBox.IsCheckedProperty);
                // ce2 is null
                // will binding still work?
                IsChecked = true;
                // of course not
    

    My previous reply was wrong, sorry

    Thursday, November 24, 2011 8:20 AM
  • Thanks Greg,

    I think the whole issue was that I was expecting the XAML bindings to work just the same as adding coded bindings.  Think I've got it all straightened out. 

     

    -Dave

    Sunday, December 18, 2011 9:27 PM