This project is read-only.


Jan 25, 2011 at 10:36 PM

What do you think about adding a check to see if newValue/oldValue are DependencyObjects before using the PropertyDescriptor instead of INotifyPropertyChanged?  This would have prevented a memory leak in our case.  Most of the objects we bind to are not WPF objects, so it's nice if the static reference caused by AddValueChanged is not present.  Makes it easier to manage memory.  Can you see any drawbacks to adding such a check?

Jan 28, 2011 at 4:36 PM


Yes, the use of a static reference when attaching via the PropertyDescriptor is very anoying. I really don't know why they designed it this way. It is the standard way though and all ms binding mechanisms make use of it. Using it has the advantage that all standard methods of 'making things observable' are reckognized. Even when a property is not observable but it's value is being set via its PropertyDescriptor (winforms/wpf bindings) obtics will be able to pick up the change.

Obtics does use the strong reference chain from source to client to keep the transformation pipeline alive as long as clients are registered for change notifications. When clients remain registered then garbage collection will happen only when the whole of source and clients is being collected. This need prevents the use of weak event registrations in obtics internally.The STATIC strong reference is not needed at all and is a major pain.

In the past obtics used to check for INotifyPropertyChanged first but this led to problems with some users who use hybrids of DependencyObjects and INotifyPropertyChanged.

Also note that not all observable things work via DependencyObjects or INotifyPropertyChanged (for example Winforms components) and for those the memory leak problem would still exist.

The best strategy may be to have your views register for change notification via the WeakEventManager or any other weak event mechanism. This is what WPF bindings do standard. If possible; always unregister any events when they are no longer needed.