With PV 5.12.0, the code of property widgets does not properly receive updated selections

Development
1

This potential ParaView bug is observed inside the code of a property widget that belongs to some self-written filter plugin. The same property widget worked fine in versions of ParaView up to 5.10, but not any more with 5.12.0

The property widget is declared like this:

class ATGPROPERTYWIDGETSMODULE_EXPORT widSelectionIds: public pqPropertyGroupWidget

Within the constructor, the following code is supposed to catch all selection changes:

    pqSelectionManager* selMan = getSelectionManager();
    connect(selMan, SIGNAL(selectionChanged(pqOutputPort*)),
            SLOT(handleChangedSelection(pqOutputPort*)));

Now withing the handleChangedSelection() function, I want to retrieve the current selection. This is not any more so simple as it used to be in the past, but the following code should bring me there:

    vtkSMSourceProxy *appendSelections = nullptr,
                     *activeSelection = nullptr;
    appendSelections = vtkSMSourceProxy::SafeDownCast(outPort->getSelectionInput());
    if((nullptr != appendSelections) &&
       (0 < vtkSMPropertyHelper(appendSelections, "Input").GetNumberOfElements()))
    {
        activeSelection = vtkSMSourceProxy::SafeDownCast(
            vtkSMPropertyHelper(appendSelections, "Input").GetAsProxy(0));
    }

In the past, the extra step to “unwrap” the active selection from some “append selection” thing was not required, but that’s fine and there is certainly a good reason for this change.

And the above code does work and I can now analyze the “active selection” in the same ways like in the past, such as checking the type of the selection, convert it if required, etc. etc.

However the new problem is that it works only once!

Meaning that if in my render view I select one cell, with “Interactive Select Cells On”, the property widget receives a signal and runs through the above code and I can retrieve the cell id of that newly selected cell.

If now I click on another cell, adding it thus to the selection, the property widget will again get a signal. But if now it extracts the “active selection” in the above way, this selection still contains only the first selected cell id, not the second! And also not any further cell.

Conclusion: It looks like the selection manager is sending the message about selectionChanged, but at the same time it is not able to provide an updated “active selection”, but instead always returns the first one on request.

Is it possible that the selection manager now needs an additional “kick” in the form of some “update” call or whatever in order to retrieve the active selection from the server side not only once, but each time there is a change?

2

Just a first answer to my question that I may have to follow: My above code assumes that there is either 0 or 1 “Input” items inside one appendSelections data set, but now I checked whether this is actually true and what I found is:

  • after the first click, there is indeed one “input item”
  • but after the second click there are indeed already two!
  • after the third there are three - etc.

I will have to add some code to further analyze these items, but my guess is that I already found the solution for my question…

3

With this I confirm that my latest guess turned out to be correct: I need to loop through all the “Input” items and collect the cell ids in order to get what I need!

Side effect is that I understand now a bit better why this concept of the appendSelections wrapper was introduced at all: The user can pile up different types of selections that are all first recorded “as they are” and collected. Only once they are finally processed, the programmer has to take care of finding out how to “merge” them in an appropriate way - like convert them into something like “cells only” or whatever.