Synchronising the WinForm data binding using .NET 2.0

The new implemented data binding functionality for .NET 2.0 seems to be quite useful. But there is one pitfall I fell in yesterday.

Normally the datasource will be updated immediatly when leaving the focus of the bound control. Yesterday I had the following scenario.

The problem:
When clicking the OK button the bound object will be verified and than stored to database. Thats the theory. Mostly this worked fine, except few times when I left the focus of an control using the TAB key. In that case sometimes the data hadn’t been bound to the data source.

After debugging I came to the conclusion that this must be a problem of asynchron events which are responsible for writing the changed data back to the data source. I’m thinking this way because the problem hit me unsteady and most time not when I was using the debugger.

private void OnLoad(object sender, EventArgs e)
{
  dateBinding.DataSource = dateClass;
}

The solution:
In the MSDN documentation I found the method BindingSource.EndEdit(). Ahh! That was the missing link I was looking for. Using this method I could force the DataSource to be updated by the WinForm.

private void OnOkButton_Click(object sender, EventArgs e)
{
  dateBinding.EndEdit();
  // do your validations here
}

Important:
The EndEdit() method does not work without any changes to other parts of the source code.

The DataSource has to implement the IEditableObject interface. You don’t have to do anything within the methods BeginEdit, CancelEdit or EndEdit. But the interface is important for the BindingSource, because it forces an deferred data binding which writes the data only back when calling the EndEdit Method.

class DateClass : IEditableObject
{
  #region IEditableObject Members

  public void BeginEdit()
  {
  }

  public void CancelEdit()
  {
  }

  public void EndEdit()
  {
  }

  #endregion

  #region Properties
  #endregion
}

Conclusion:
Even if you do not have the problems with the data binding that I had, I would recommend to use the data binding mentioned above.

Implementing the IEditableObject and using the EndEdit() method is the most safe way to implement the databinding functionality of .NET 2.0. That is because you always know the state of your datasource and you have the ability to control the state of the data.

Addendum – 2 days later
I have to apologize to Microsoft, because it was’nt their fault – I found the bug. The problem was that I bound one data field by mistake to two UI controls. This caused unpredictable results when writing the results back to the data object every time the control lost or got the focus. That’s why my second solution (explained above) solved the problem, because I had one defined write-back point in my code.

Anyway – what did I learn?

1. It’s better to control the data binding first if you make strange observations on your data binding.
2. Having one defined write-back point can help you to reproduce the wrongdoing of your application more easy.

Any suggestions to this are welcome.