In 2.1, I had an ERLB derived object bound to a grid. When the user double-clicked on the grid, a modal form with a navigator would be displayed, allowing changes to the current item contents. ERLB would save the object fine when you hit "next" on the navigator.
In 3.0, it appears that ERLB doesn't resume editing for the current item when the form is displayed (it "saves" the item just before the form appears).
So, when I press "next" for the current/first item when the form is displayed, nothing happens, and changes aren't saved. However, it works for every item after that because the navigator and ERLB are attached to the same binding source.
Can someone point me in the right direction as to how to nudge ERLB into re-editing the current row in this situation?
(Note that we aren't tied to a modal form implementation -- everything is built as component controls and the same interface is displayable in a docking panel, side-by-side tab, or even split-screen on the same form with the grid, but they all have the same problem -- ERLB isn't "editing" the object for them anymore once you leave the grid).
It's possible I have this figured out, but I would need to experiment more.
When I first started testing with 3.0.2, I didn't have AutoCloneOnUpdate turned on. So, the ERLB was cloning the first object in the list (even though it wasn't dirty) just as part of the normal EndEdit before the form was displayed, and the bound controls were thus stuck with a stale, orphaned object no longer part of the ERLB.
However, once they navigated to another row, they obtained a live object.
I since turned AutoCloneOnUpdate on, and the object doesn't get cloned unless it is dirty, so it seems to avoid the above behavior.
Copyright (c) Marimer LLC