On WinForms complex binding controls (DGV, ListBox, etc) the BindingContextChanged is fired exactly once, as can be seen on the attached WinForms sample.
On the attached Wisej sample, the equivalent controls fire this event twice. This check is made on the SyncedList control – just press the SyncedList button.
The samples also include the BoundTreeView control that only fires the BindingContextChanged event once, both on WinForms and Wisej.
Thank you for the excellent test app. We’ll use it for more data binding tests.
About the BindingContextChanged count, the result of 2,2,1 (dgv, list, tree) is correct. The event is fired when the BindingContext is first created and then it’s fired again when the control is created the first time when made visible in order to update the bindings.
In your winforms sample the count is 1,1,1 only because there is an InitLayout overload that forces the creation of the winforms handle, which results in a premature call to CreateControl before the InitializeComponent is finished, which results in the BindingContext being created too soon. If you comment out the WinSDK call that forces the handle creation you get the same 2,2,1.
This is the function in the winforms sample that forces the handle creation by calling ShowScrollBar() when the control is not yet created.
protected override void InitLayout()
ShowScrollBar(Handle, SbHorz, false);
You are right. All I had to do is to prevent BindingContextChanged to execute when InitLayout runs. Now every complex data binding control raises BindingContextChanged event twice, be it on Windows Forms and on Wisej. I don’t attach the fixed sample because I intend to attach it to another report, about another issue I’m facing.
Please login first to submit.