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>( En开发者_运维知识库umerable.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.
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 PropertyChangedCallback
s on dependency properties bound to your property will not be called.
For simplicity I've ignored IValueConverter
s 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.
I have the same issue in my code and Luke is right. I called SetValue by mystake inside the PropertyChangedCallback causing a potential infinite loop. WPF prevent this disabling silently the callback !!
my WPF UserControl is
PatchRenderer
my C# property is Note:
[Description("Note displayed with star icons"),
Category("Data"),
Browsable(true),
EditorBrowsable(EditorBrowsableState.Always),
DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]
public int Note
{
get { return (int)GetValue(NoteProperty); }
set { SetValue(NoteProperty, value); /* don't put anything more here */ }
}
my WPF property
public static readonly DependencyProperty
NoteProperty = DependencyProperty.Register("Note",
typeof(int), typeof(PatchRenderer),
new PropertyMetadata(
new PropertyChangedCallback(PatchRenderer.onNoteChanged)
));
private static void onNoteChanged(DependencyObject d,
DependencyPropertyChangedEventArgs e)
{
// this is the bug: calling the setter in the callback
//((PatchRenderer)d).Note = (int)e.NewValue;
// the following was wrongly placed in the Note setter.
// it make sence to put it here.
// this method is intended to display stars icons
// to represent the Note
((PatchRenderer)d).UpdateNoteIcons();
}
You might be having an issue where the contents of the collection is changing but not the actual instance. in this case you'll want to use an ObservableCollection and do something like this:
public static readonly DependencyProperty VisibleItemsProperty =
DependencyProperty.Register(
"VisibleItems",
typeof(IList),
typeof(MyFilterList),
new FrameworkPropertyMetadata(null, FrameworkPropertyMetadataOptions.AffectsRender, new PropertyChangedCallback(VisibleItemsChanged)));
private static void VisibleItemsChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
var myList = d as MyFilterList;
if (myList == null) return;
myList.OnVisibleItemsChanged(e.NewValue as IList, e.OldValue as IList);
}
protected virtual void OnVisibleItemsChanged(IList newValue, IList oldValue)
{
var oldCollection = oldValue as INotifyCollectionChanged;
if (oldCollection != null)
{
oldCollection.CollectionChanged -= VisibleItems_CollectionChanged;
}
var newCollection = newValue as INotifyCollectionChanged;
if (newCollection != null)
{
newCollection.CollectionChanged += VisibleItems_CollectionChanged;
}
}
If you just instantiate a MyFilterList
and set VisibleItems
via code like this:
var control = new MyFilterList();
control.VisibleItems = new List<string>();
control.VisibleItems = new List<string>();
You will likely see the PropertyChangedCallback happen every time. Meaning, the problem is with the binding, not the callback. Make sure you don't have binding errors, you're raising PropertyChanged
, and you're not breaking the binding (e.g. by setting VisibleItems
in code)
精彩评论