Databinding Confusion

WARNING: This is a purely techie-post for the benefit of some poor sap like me who has yet to discover the strange behavior that I have just found in Visual Basic 2005 Express Edition.

I used the databinding form wizard to create some forms in vb 2005, which automatically provides a BindingSource, a BindingNavigator and a TableAdapter bound to your DataSet.
The BindingNavigator is controlled by a wizard-generated toolstrip, which contains the standard data-navigational buttons; movenext, moveprevious, movefirst, movelast, addnew, save and delete.
The save button calls a validate, endedit and update methods in order to commit your data to the data store.
What I found is that attempting to AddNew and then changing your mind and clicking MovePrevious results in an error which complains that you've tried to enter a null value where it doesn't belong. Actually, you intended to abandon the null values and let them go away. However, somewhere they are fighting to live; in code that Visual Studio won't let you see, the bindingnavigator, or the tableadapter is screaming "Take these null values or DIE!!!" To which the DataSet blythley responds. "Nuh-uh."
As it turns out there is a simple remedy, though finding it cost me some of my youth.
When someone tries to move off of a new or edited record, you can give them a final chance to decide what they mean to do by presenting them the options to Save, Abandon, or Don't Move using code like the following:


Private Sub BindingNavigatorMovePreviousItem_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles BindingNavigatorMovePreviousItem.Click
Try
Dim yesno As MsgBoxResult
yesno = MsgBox("Do you want to save the edits you made to this record before moving?", MsgBoxStyle.YesNoCancel)
Select Case yesno
Case MsgBoxResult.Yes
Me.TblClientsBindingNavigator.Validate()
Me.TblClientsBindingNavigator.Update()
Case MsgBoxResult.No
Me.TblClientsBindingSource.CancelEdit()
Case MsgBoxResult.Cancel
Exit Sub
End Select
Catch ex As Exception

End Try
End Sub

It is the CancelEdit() method that tames the shrewlike tableadapter. I wish I knew how, but for now I only thank heaven that the screaming has subsided.