As discussed in the issue I opened, https://github.com/fsprojects/FSharp.Desktop.UI/issues/23 , these are my additions to the framework that allow for easy computed properties on the model. Before, computed properties could not be bound to effectively, because they would never have NotifyPropertyChanged called on them unless you had some strange event-soup to do this.
The framework originally got around this by the [<DerivedProperty>] annotation on the field that, at binding time (when you call Binding.OfExpression) would create a multibinding to tie the property to its dependencies. This works fine, but it is only compatible with WPF.
This commit adds optional syntax for modeling the dependencies of your data directly, so that computed properties get NotifyPropertyChanged when their parents get NotifyPropertyChanged. It does this by hijacking the Abstract & PropertySetter propertyName match in the implementation of IInterceptor.Intercept in Model.fs.
I understand if there is an aversion to duplicate functionality, or if there is an aversion to add features to support WinForms when this is primarily a WPF framework.
As discussed in the issue I opened, https://github.com/fsprojects/FSharp.Desktop.UI/issues/23 , these are my additions to the framework that allow for easy computed properties on the model. Before, computed properties could not be bound to effectively, because they would never have
NotifyPropertyChangedcalled on them unless you had some strange event-soup to do this.The framework originally got around this by the
[<DerivedProperty>]annotation on the field that, at binding time (when you callBinding.OfExpression) would create a multibinding to tie the property to its dependencies. This works fine, but it is only compatible with WPF.This commit adds optional syntax for modeling the dependencies of your data directly, so that computed properties get
NotifyPropertyChangedwhen their parents getNotifyPropertyChanged. It does this by hijacking theAbstract & PropertySetter propertyNamematch in the implementation ofIInterceptor.InterceptinModel.fs.I understand if there is an aversion to duplicate functionality, or if there is an aversion to add features to support WinForms when this is primarily a WPF framework.