Obtics doesn't use weak events especially because WPF does. I often have properties that return IValueProviders that are created (or retrieved from the carrousel) on the fly (not stored in a local field or anything). WPF can bind directly to the Value
of the returned IValueProvider. As long as WPF has an event registration the non-weak events (from the source up) will ensure that the transformation pipeline will remain allive. If Obtics would use weak events the pipeline would be garbage collected
and no more updates would get through to the WPF binding.
When WPF is done it unregisters. The transformation pipeline in turn will unregister from its source and can be garbage collected thus immediately reducing memory stress.
There is an issue though with WPF bindings to objects that themselves have a strong reference path to the target of the binding. The binding uses the PropertyDescriptor.AddValueChanged method to register for property change notifications. This in turn
will store a strong reference to the property owning object in a static container! And that means that because of the strong reference path from the object to the binding target that target will never be garbage collected and the binding never cleared ->
So; if you have a WPF element that is not meant to stay arround for ever. Don't bind it to an observable expression that has that same element or a parent of that element as one of it's dependencies. I usually create a backing store (ValueProvider.Dynamic()) for
a value my observable expression depends on and then bind WPF to that backing store. WPF can then safely bind to my observable expression without the risk of creating the mentioned problem. So I don't use TextBox.Text directly in my observable expression but
create a field IValueProvider<string> t = ValueProvider.Dynamic<string>(); I bind TextBox.Text to that field and base my observable expression on it. Thus preventing a strong reference path from my observable expression to the TextBox.