IEditableObject.CancelEdit is not called for AddRecords, and I think I understand why, because of the unique internal handling for that grid record. However, I have some logic in CancelEdit that I need also for the AddRecord (namely to reset a dirty data flag after cancellation), and I was wondering where to put that code for the AddRecord. XDG.RecordUpdateCanceling/ed is okay, and though not as smitten with MVVM as others, I like to keep code behind to a minimum. Any ideas? Thanks.
Yes
You're absolutely right. I'm in crunch mode now and I was posting to you guys as I worked this one out. I'm using a composite pattern with hierarchical viewmodels, and there's alot going on.
Are you a developer Andrew?
The item is removed in that method so perhaps just get the item before calling the base, call the base (so it gets removed) and then do your clean up before returning from that method.
Thanks for the heads-up on that; didn't know it. But yes, I was deriving from BindingList<T>. Interesting thing though, my dirty add record is still in the list when this CancelNew is called (just as with XDG.UpdateCancelled). So I'll putting some code in overridden BindlingList<T>.RemoveItem next. It's definitely out of the list there.
Does the list you're using implement ICancelAddNew (e.g. BindingList<T> does)? If so then that is being called when the add new is cancelled so maybe you can use that (e.g. CancelNew on the BindingList<T> is virtual so you might be able to override it and do what you need there).