Fix lost index on selection change in Attribute Table #52045
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue was that the index always jumps to the first position when I make a feature selection (yellow):
IndexLostOnSelection.webm
The original implementation intended that the index jumps to the first feature in the made selection (in case the indexed feature is currently not in the selection - otherwise the index should presist). But this did not work: Problem was that when the connection to the lambda updating the index has the parameter of it's initialization. Means
inSelection
was alwaysfalse
and with this the index received 0 (first position).This fix decapsulates the update function from where the timer to trigger starts. Since we cannot pass the parameter
inSelection
because of the timer I created two timer (and with it two connections).I decided against a quick fix with deconnect/connect the lambda function on every
ensureEditSelection
because of the fragility of those triggers in the attribute table. The proposed sollution is in my opinion more secure.Fixed sollution looks like this:
selectiontakesindex.webm