This seems like a simple problem but I'm not sure what I'm missing.
If I call UndoChanges on an object in an ERLB+Grid, the Grid doesn't show the object changes immediately. However, I know it's holding the same reference because as soon as I type any value in a field on the adjacent form and tab out, the grid shows the updated value.
So, what event should fire to tell the the grid to update itself when UndoChanges is called on an object in the list?
I can live with it as is, because the grid updates itself immediately when you click back on the row, but it's not nice aesthetically. Old values, error provider icons, etc, are still shown in the grid until you click on it or change a value manually.
Windows Forms data binding has one very simple rule:
You can never call methods on your business object while the object is bound to the UI. You must always interact with the BindingSource instead.
Or you can unbind from the UI, interact with the object, then rebind to the UI.
This is true for ERLB as well as everything else.
If you want to do an undo - call CancelEdit() on the BindingSource - that'll cancel edits to the current row.
I've turned off IEditableObject -- does this still apply?
I'd think the object would ignore the call from CancelEdit() on the BindingSource since DisableIEditableObject = = true.
Yeah, you are in uncharted waters here…
ERLB is designed to react to data binding. If you turn off data
binding you’re outside of the design scope.
I suspect that you’ll need to get your object to raise a
PropertyChanged(null) event – which it should do when you call
CancelEdit() (though not necessarily UndoChanges()). That should trigger a
ListChanged event from ERLB that tells the UI to refresh.
Rocky
OK. I actually was calling CancelEdit(), but I think it almost immediately calls UndoChanges() -- and I don't see the PropertyChanged(null) call but I'll look further -- that may be all that's missing.
I may be getting confused on the term "data binding" versus IEditableObject.
My understanding is that everything is still data bound, the object just ignores the calls to BeginEdit(), EndEdit(), etc. raised by WinForms rather than doing the undo state management it would otherwise. So, I wouldn't expect to see any change in behavior at all except as far as the handling undo (and saving when you move from row to row). I've already called BeginEdit on the object myself, so this is exactly what I want it to do.
Copyright (c) Marimer LLC