Binding causes StackOverflow

Question

Im not sure what I am doing wrong here.

Lets say, I have two UserControls BoxAand BoxB. Both have a DependencyProperty called Text

Answer 1

If you are building a UserControl with bindable properties (i.e. dependency properties), you must under no circumstances explicitly set the UserControl's DataContext, be it to the control instance or to any private view model.

If you do that, a Binding like

<local:BoxB Text="{Binding Title}">

will no longer work. That Binding expects a Title property in the object in the current DataContext. The DataContext property value is usually inherited from the parent element of the UserControl, e.g. the Window. However, since you've explicitly set the DataContext, this mechanism is avoided.

This becomes particularly confusing with equally named properties in UserControls. When you write

<local:BoxA Text="{Binding Text, ...}"/>

in UserControl BoxB, your expectation is that the Binding source property is BoxB.Text. In fact it is BoxA.Text, because BoxA's DataContext is the BoxA instance.

---

So remove any

DataContext="{Binding RelativeSource={RelativeSource Self}}"

lines and write the Bindings in the UserControl's XAML with RelativeSource like this:

<TextBox Text="{Binding Text, UpdateSourceTrigger=PropertyChanged, Mode=TwoWay},
                RelativeSource={RelativeSource AncestorType=UserControl}"/>

<local:BoxA Text="{Binding Text, UpdateSourceTrigger=PropertyChanged, Mode=TwoWay},
                   RelativeSource={RelativeSource AncestorType=UserControl}"/>

Answer 2

With any form of Change Notificaiton, one danger is what I call the "Ping Pong" problem. Example:

1. Property A changes.
2. Property B is changed to match A.
3. Property B changed.
4. Property A is changed to match B.
5. Recurse to 1

In order to avoid that, the exampel code for Properties with Change notificaiton looks like this:

public string PhoneNumber
{
    get
    {
        return this.phoneNumberValue;
    }

    set
    {
        if (value != this.phoneNumberValue)
        {
            this.phoneNumberValue = value;
            NotifyPropertyChanged();
        }
    }
}

If the input is the same as output, nothing is done. The squence goes:

1. Property A changes
2. Property B is chagned to match A
3. Proeprty B changes
4. Property A notices it already has that value anyway, so nothing is done.

My best guess is that WPF Elements have no such protection. It is one of those cases were "trying to be smart could result in being really dumb".