Possible problem: void System.ComponentModel.IEditableObject.CancelEdit()

vdhant posted on Thursday, January 03, 2008

Hi guys
Just wondering why in the void System.ComponentModel.IEditableObject.CancelEdit() method does it implement the check to see if it should remove itself from the parent collection and the normal remove child does not? At least for me it is not obvious why this is so. I would have thought that this logic would be the same regardless of whether .net is calling the method thought the explicit implementation or the implicit. Just thought that i would ask the question.
Thanks
Anthony

void System.ComponentModel.IEditableObject.CancelEdit()
{
if (!_disableIEditableObject && BindingEdit)
{
CancelEdit();
if (IsNew && _neverCommitted && EditLevel <= EditLevelAdded)
{
if (Parent != null)
Parent.RemoveChild(this);
}
}
}

RockfordLhotka replied on Thursday, January 03, 2008

In my mind the CancelEdit() behavior is the correct behavior. This IEO.CancelEdit() behavior only exists because of the way Windows Forms data binding interacts with IEO for in-place editing in a grid.

In fact, Microsoft disliked this so much that in .NET 2.0 they changed data binding to not use it either. Instead, they did what should have been done in the first place and moved the removal of the child into the collection (ICancelAddNew) where it belongs.

I have left this code in CSLA to support 1.x style data binding (in particular the use of older grid controls).

vdhant replied on Thursday, January 03, 2008

Ok cool that seems reasonable. So just conforming that it is there simply for backwards compatibility and that if one wasn't interested in backwards compatibility the bolded code would be removed from IEO.CancelEdit() and the ICancelAddNew interface that you have included in the list base classes will cover the functionality that is removed from CancelEdit.
Is that correct?
Thanks
Anthony