Databinding

BcfViewManagers are the components adding data-binding to a BcfDataSet. Because of differences in WPF/XAML and winforms binding there are two different libraries:

• CalculationWorks.ViewModel.Windows for WPF and XAML
• CalculationWorks.ViewModel.Forms for winforms.

WPF/XAML binding uses INotifyPropertyChanged, INotifyDataErrorInfo and INotifyCollectionChanged for binding.

The two collection-item base-types are:

• CalculationWorks.ViewModel.WindowsBcfRowView: is prepared for, but does NOT implement INotifyPropertyChanged and INotifyDataErrorInfo.
• CalculationWorks.ViewModel.WindowsBcfCommonRowView: it inherits CalculationWorks.ViewModel.WindowsBcfRowView and implements INotifyPropertyChanged and INotifyDataErrorInfo.

When declaring bindings use always BindsDirectlyToSource = true.

WinForms binding uses IDataErrorInfo, IBindingListView and ITypedList for binding.

The two collection-item base-types are:

• CalculationWorks.ViewModel.FormsBcfRowView: is prepared for, but does NOT implement IDataErrorInfo.
• CalculationWorks.ViewModel.FormsBcfCommonRowView: inherits CalculationWorks.ViewModel.FormsBcfRowView and implements IDataErrorInfo.

CalculationWorks.ViewModel.FormsBcfCommonRowView does not implement INotifyPropertyChanged. This is because of binding-update-behavior when combining list-binding and property-binding in winforms. Feel free to implement INotifyPropertyChanged on a class inheriting CalculationWorks.ViewModel.FormsBcfCommonRowView and use it as item base-class (see: Forms-ViewManager/"RowView Base Class") to support property-binding.

Caution
Many winforms UI-components like grids and lists support notification by INotifyPropertyChanged. The issue is; they cause a full-row-update on every property-changed, even if bound list implements IBindingListView.

CalculationWorks.ViewModel.FormsBcfViewManager is default view-manager base-class. Bindings work like .net-DataSet bindings.

Tip
Using CalculationWorks.ViewModel.FormsBcfHierarchicalViewManager instead. You can define root and branch binding-sources on view-manager itself.

A frequently asked question using winforms databinding is how to extend a grid-row with parent or child properties. Using AddParentRowViewProperties and AddChildRowViewProperties allows exactly this.

The life-cycle strategy is different between rows and row-views. While row life-cycle depends on undo/redo (memory-undo undo-delete: restore row-object; file-undo: create new one), a row-view once deleted will never been restored.

If you need to identify a row anywhere in UI-logic use RowId rather than row-references, rowview-references or primary keys. RowId and RowViewId are equal for the same entity.

Ignoring recurrent update. Change-notification is part of transactions commit phase. So change-handlers can not successfully cause a data-update. Bad data-binding often causes unexpected data-update e.g. having an row (Value: string; AllowedValues: string[]), bound as combox-value and combobox-items - and update both in one transaction (some controls "repair" data when updating a property. If value is changed first and new-value is not in old-items, it is set to first of old-items!!, etc.). Those updates are ignored silently - if you want to be notified, subscribe SuppressingRecurrentUpdate.

BcfDataSet stores values in typed cells without boxing. BcfViewManager uses boxing to store values. So use untyped value access against views is OK; untyped value access against tables and rows causes boxing.

To reduce memory allocation and speedup view-manager update, you can exclude columns and tables from view-manager (see BCF-Editor: Table Settings, Column Settings).

ApplyFilter suppresses row-views in a view. Filter suppresses rows in entire view-manager.