From d3800564d810d8ed9777083fa22a51199c21c0a4 Mon Sep 17 00:00:00 2001 From: Janet Vorobyeva Date: Tue, 19 Sep 2023 00:03:44 -0700 Subject: [PATCH] Fixed row-delete bug If several sections cyclically cursor-linked, and a row was deleted, the sections would go to different places. (default behavior on row delete is jump to row 0, but active section's cursor explicitly keeps its index on row-delete. The setCursorPos from this WAS actually called last, so should have correctly set cursorEdited(), but didn't get called) --- app/client/components/Cursor.ts | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/app/client/components/Cursor.ts b/app/client/components/Cursor.ts index 2857ef60..e7156583 100644 --- a/app/client/components/Cursor.ts +++ b/app/client/components/Cursor.ts @@ -183,6 +183,17 @@ export class Cursor extends Disposable { this.fieldIndex(cursorPos.fieldIndex); } + // NOTE: cursorEdited + // We primarily update cursorEdited counter from a this._properRowId.subscribe(), since that catches updates + // from many sources (setCursorPos, arrowKeys, save/load, filter/sort-changes, etc) + // However, when deleting a row with several sections linked together, there can be a case where this fails: + // When GridView.deleteRows calls setCursorPos to keep cursor from jumping after delete, the observable + // doesn't trigger cursorEdited(), because (I think) _properRowId has already been updated that cycle. + // This caused a bug when several viewSections were cursor-linked to each other and a row was deleted. + // We can explicitly call cursorEdited again here. It'll cause cursorEdited to be called twice sometimes, + // but that shouldn't cause any problems, since we don't care about edit counts, just who was edited latest. + this.cursorEdited() + } finally { // Make sure we reset this even on error this._silentUpdatesFlag = false; }