I've run into an issue with RestoreCurrentRowIndex and Undo. In my application I have a business rule that checks for duplicates by looping through the records in the business object using move commands or GetEnumerable. Before entering the loop I save off the current row index using SaveCurrentRowIndex. After the loop is completed I call RestoreCurrentRowIndex(False). At this point everything is okay. However if UndoCurrentRowOnly is called on the BO, the CurrentRowIndex is not updated and the Index points beyond the current number of rows. Attached is a simple example that shows the issue. The BO is mapped to the SF demo data base although it doesn't access it.

I've been able to work around the issue by storing the CurrentRowIndex off to a local variable and restoring the current row using Move.Absolute.

-Larry

Well, the Undo() method uses the SaveCurrentRowIndex and RestoreCurrentRowIndex internally, so after the call to Undo(), then "saved" current row index will most likely be -1, since that's the default and your save was wiped out.  So, in this case, I would probably recommend to just store it off manually.

Actually after calling Undo(CurrentRowOnly) the CurrentRowIndex remains unchanged. Looking at the source for BusinessLayer I can see why this is happening. When Add() is called, BusinessLayer calls SaveCurrentRowIndex which sets the private variable  _SavedCurrentRowIndex to the current index. When RestoreCurrentRowIndex() is called it uses _SaveCurrentRowIndex to restore the CurrentRowIndex and then sets _SavedCurrentRowIndex to -1. When Undo is later called RestoreCurrentRowIndex does nothing since the value of _SavedCurrentRowIndex is -1. Since I haven't spent a lot of time looking at BusinessLayer I'm not clear on why _SavedCurrentRowIndex needs to be cleared when the current row index is restored, but not clearing it would fix this issue.

-Larry

The reason that we clear the value is so that additional calls to RestoreCurrentRowIndex will do nothing after the first one that actually restores it.  There are a few places in code where RestoreCurrentRowIndex might be called more than once with only one SaveCurrentRowIndex, but the index itself might have changed in between the calls to Restore, so we didn't want it changing the value again.