Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • ParaView ParaView
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,846
    • Issues 1,846
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 88
    • Merge requests 88
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ParaView
  • ParaViewParaView
  • Issues
  • #19808

Closed
Open
Created Mar 30, 2020 by Cornelis Bockemühl@coboContributor

selectionChanged issued too early on grow/shrink selection

Working with PV5.8 "official release", I see that the very nice new selection functions "grow" and "shrink" still have some kind of hidden problem.

The point is that in a derived custom application, I am catching the selectionChanged signal from the selection manager - assuming that during this call, the current selection is already updated and can be used! This is true for all the other selection functions, but obviously not for these two new functions: the selection is still like it was BEFORE applying the grow/shrink operation - which AFTERWARDS is indeed happening! The latter is the reason why I am calling it a "hidden problem", because for all those functions that do not rely on an up-to-date selection already during the selectionChanged signal will not run into any kind of problem.

Some first analysis:

Looking into the code of pqSelectionManager, I see that in the expandSelection() function, the signal is emitted. Looking then into the following function, which is clearSelection(), the entire logic looks a bit similar, but before the signal is emitted, there is a call to Implementation->SelectedPorts->clear() which somehow looks like it is doing the real "cleanup" before the signal is emitted.

On the other hand, the expandSelection() is called from pqRenderViewSelectionReaction::beginSelection() - and I am asking myself if this is indeed the right place to emit already the selectionChanged() ??

I have to say that I am still on the way to explore the situation, but I am afraid that this is indeed a but - and I suspect that it is in this calling order. Maybe there shouild be another action inside the endSelection() function that triggers the selectionChanged() ??

I am certainly going to further investigate, but I wanted to share my current findings already - in the hope that somebody more familiar with the code can see the problem and the correct fix more quickly.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking