Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gracefully handle the deletion of an edited table cell #7552

Merged
merged 1 commit into from Apr 5, 2023

Conversation

vlaaad
Copy link
Contributor

@vlaaad vlaaad commented Apr 5, 2023

User-facing changes: deleting a row with a currently-edited table cell no longers throws an exception.

Technical notes: JavaFX strikes again... This looks like a helpful behavior they introduced in some update — committing a change of a cell that loses focus. Unfortunately, it happens to be executed in the order we didn't anticipate. The user clicks the "Remove" button -> we execute the :remove-table-selection handler -> we now get new items -> we set new items on a table view -> table view notices that we edit the table and commits the edit before replacing the cell -> we execute the :commit-table-edit handler on a new items vector, but the edit is applied as if to the old items vector. I.e. we track an index to change while editing, and it corresponds to the old vector. So, if we remove the last item that was edited, the index will be out of bounds by one. Applying the edit is (assoc items index new-value), which will act as conj in case of off-by-one assoc. Just canceling the edit will prevent JavaFX from committing it which is a way out of this mess.

Fixes #6924

User-facing changes: deleting a row with a currently-edited table cell no longers throws an exception.

Technical notes: JavaFX strikes again... This looks like a helpful behavior they introduced in some update — committing a change of a cell that loses focus. Unfortunately, it happens to be executed in the order we didn't anticipate. The user clicks the "Remove" button -> we execute the `:remove-table-selection` handler -> we now get new items -> we set new items on a table view -> table view notices that we edit the table and commits the edit before replacing the cell -> we execute the `:commit-table-edit` handler on a new items vector, but the edit is applied as if to the old items vector. I.e. we track an index to change while editing, and it corresponds to the old vector. So, if we remove the last item that was edited, the index will be out of bounds by one. Applying the edit is `(assoc items index new-value)`, which will act as `conj` in case of off-by-one `assoc`. Just canceling the edit will prevent JavaFX from committing it which is a way out of this mess.

Fixes #6924
@vlaaad vlaaad requested a review from matgis April 5, 2023 13:12
Copy link
Contributor

@matgis matgis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to work! LGTM!

@vlaaad vlaaad merged commit 904d047 into editor-dev Apr 5, 2023
5 checks passed
@vlaaad vlaaad deleted the DEFEDIT-6924 branch April 5, 2023 14:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants