This points out the last action done in the detail edit form is locating on the last record. A TABLEUPDATE(T,..), TABLEUPDATE(1,...), or TABLEUPDATE(2,...) saving changes of all rows would do that.
As we lately had a discussion about why for example a GOTO might cause a range error, instead of memorizing the record number I'd recommend remembering the ID of a record and to reposition to that with a SEEK. Ideally, the detail form, as it obviously works in the same datasession, should do that as part of the cleanup code. So it should initially memorize the current ID and go back to that as the last step before releasing itself. The other option is a private datasession, where the detail form would need the ID of the record to edit, would open up the table again and position on its own workarea, but would therefore not change anything for the form listing records, despite of course acting on the same DBF and record, which would also reflect after a grid.refresh. An advantage of using the same datasession is, you don't need to save buffered changes before the calling form sees them, when the two forms share the same workarea they also share that buffer. You still need to refresh controls for that to show, but in principle, you can have an editform, which edits immediately also reflect in the columns listed in a grid on the calling form. That's the one advantage, and the other is not always having the full roundtrip to the DBF, which could also mean field and table rules checking and triggers, if the DBF is part of a DBC. That's all reasons pointing out shared datasession is good for that case of editing a record. It could be integrated in one form, having it in a separate form in this case doesn't make it an independent form, so it's okay to stay in the thereby shared datasession, even though private datasessions are an easy way out of such mutual influences, it's a wanted side effect here, aside of switching the row. As you know you only edit one record, you can of course also only use TABLEUPDATE() for committing changes to the current row only.
Besides all that, there is one property of row highlighting, that controls whether the highlighting is persistent if the focus moves from the grid elsewhere or even to another form. This would never explain why the highlight moves to the bottom, though, I'm quite confident something like a TABLEUPDATE of all rows is done, which ends at the last row of a table, not just the last edited row.
Bye, Olaf.
Olaf Doschke Software Engineering