Unified Selection event to re-state selection

[tomas-kvaraciejus-bentley]

Our application allows for interactive review of changes made to an iModel. Elements are constantly added to and removed from the iModel visible in the Viewport. All possible changes are still stored on our end, meaning it's normal for us to have references to elements that do not exist in the iModel, but that can be added at any time.
This means that sometimes our internal selection state tracks elements that do not exist in the iModel as 'selected' in one of our tables. This is completely intentional, but from the user side this leads can lead to some issues. For example, it's expected that clicking anywhere on the background of the Viewport (and not hitting an element) will deselect all elements. Unfortunately, since the tracked element doesn't exist in the iModel and wasn't selected there, nothing is deselected, the selection state is not changed, and no event is fired. Other adjacent issues that I won't go into detail about also show up because of this.

What I'd like to propose is some kind of Selection event to simply re-state what is currently selected on any given click of the Viewport. That way we'd know that some sort of interaction happened, and could refresh our internal state accordingly, even if no element selection was actually changed in the iModel.
Would something like this be possible?

[saskliutas]

Hey, I want to clarify on some things.

• Are these elements stored in unified-selection or are their selection state completely maintained by your application?
• I guess everything works correctly when user click hits element? Replace selection event is raised and you can update your selection state? What about other interactions clicking already selected element, etc?
• You need to keep removed element selected even when it is not present in viewport because some other UI should still present this selection?

[tomas-kvaraciejus-bentley]

Hi,

1. We try to synchronize the Selection state between two sources of truth. When an event fires in SelectionStorage we update our frontend state, and when an update happens in the frontend we likewise update SelectionStorage.
2. Everything else works perfectly. The issue I'm describing only occurs when the user tries to 'deselect' and element that doesn't exist in the model (nothing is selected in the Viewport so clicking on the background doesn't raise a 'deselect' event, although the element is selected in our Frontend code and intuitively the user expects that clicking on the Viewport will deselect it from everywhere else).
3. Not necessarily. What I was suggesting was a way of letting us know the Selection state on any update to the Viewport (including a click on the background), but any solution that would address our problem would work just as well.

[grigasp]

Viewport events <> Selection events, when user clicks in a viewport with nothing selected there, the event doesn't even get to our synchronizer.

Why do you need that "internal selection state" acting as the second source of truth?

[saskliutas]

3. Not necessarily. What I was suggesting was a way of letting us know the Selection state on any update to the Viewport (including a click on the background), but any solution that would address our problem would work just as well.

If you don't need to keep removed elements in your selection state maybe it would be possible to cleanup your frontend selection state when removal of element is applied? Or you don't have a way to figure out when and which element was removed?

Other way to handle this would be to customize the default SelectionTool. It handles interactions with viewport and you probably could extend processMiss method to cleanup your selection state.