WPF: PropertyChangedCallback triggered only once

Question

I have a user control, which exposes a DependencyProperty called VisibileItems Every time that property gets updated, i need to trigger another event. To achieve that, i added a FrameworkPropertyMetadata with PropertyChangedCallback event.

For some reason, this event gets called only once, and doesn't trigger the next time VisibleItems is changed.

XAML:

<cc:MyFilterList VisibleItems="{Binding CurrentTables}"  />

CurrentTables is a DependencyProperty on MyViewModel. CurrentTables gets changed often. I can bind another WPF control to CurrentTables, and i see the changes in the UI.

Here is the way i wired VisibleItems with PropertyChangedCallback

public static readonly DependencyProperty VisibleItemsProperty =
    DependencyProperty.Register(
    "VisibleItems",
    typeof(IList),
    typeof(MyFilterList),
    new FrameworkPropertyMetadata(null, FrameworkPropertyMetadataOptions.AffectsRender, new PropertyChangedCallback(VisiblePropertyChanged))

    );

public IList VisibleItems {
    get { return (IList)GetValue(VisibleItemsProperty); }
    set { SetValue(VisibleItemsProperty, value); }
}

by stepping into VisiblePropertyChanged, i can see that it gets triggered the first time CurrentTables gets set. but not subsequent times.

UPDATE

as some of you questioned the way CurrentTables is modified, it is re-assigned completely on change:

OnDBChange()...
CurrentTables = new List<string>(MainDatabaseDataAdapter.GetTables(this.SelectedServer, this.SelectedDatabase));

this line gets called on every change, but my VisiblePropertyChanged handler gets called only the first time.

UPDATE

if i assign VisibleItems directly, the handler does get called every time!

TestFilterList.VisibleItems = new List<string>( Enumerable.Range(1, DateTime.Now.Second).ToList().Select(s => s.ToString()).ToList() );

So, it looks like the problem stems from the DependencyProperty (VisibleItems) watching another DependencyProperty (CurrentTables). Somehow the binding works on first property change, but not on subsequent ones? Attempting to inspect this issue with snoop as some of you suggested.

Answer 1

Are you setting a 'local' value (i.e. assigning directly to a dependency property setter) to a dependency property that also has a OneWay binding on it? If so, setting the local value will remove the binding, as mentioned on the the MSDN dependency property overview:

Bindings are treated as a local value, which means that if you set another local value, you will eliminate the binding.

The dependency property mechanism doesn't have much else it can do when it gets asked to store a local value on a dependency property. It can't send the value through the binding because the binding 'points' the wrong way. After being set to the local value, it's no longer showing the value it got from the binding. Since it's not showing the value from the binding any more, it removes the binding.

Once the binding's gone, the PropertyChangedCallback will no longer get called when the source property for the binding changes its value. This may be why the callback isn't being called.

If you set the binding to be TwoWay, the binding system does have somewhere to store the 'local' value you've set: in the binding's source property. In this case, there's no need to eliminate the binding as the dependency property mechanism can store the value in the source property.

This situation does not cause a stack-overflow because the following happens:

• Dependency property receives 'local' value.
• Dependency property mechanism sends value 'backwards' along binding to source property,
• Source property sets property value and fires PropertyChanged,
• Dependency property mechanism receives PropertyChanged event, checks new value of source property, finds that it hasn't changed and does nothing further.

The key point here is that if you fire a PropertyChanged event for a property whose value hasn't changed, any PropertyChangedCallbacks on dependency properties bound to your property will not be called.

For simplicity I've ignored IValueConverters in the above. If you do have a converter, make sure that it is correctly converting values in both directions. I've also assumed that the property at the other end is a view-model property on an object implementing INotifyPropertyChanged. There could have been another dependency property at the source end of the binding. The dependency property mechanism can handle that as well.

As it happens, WPF (and Silverlight) contain no detection of stack overflows. If, in a PropertyChangedCallback, you set the value of the dependency property to be different to its new value (e.g. by incrementing an integer-valued property or appending a string to a string-valued property), you will get a stack overflow.