The “active scalar” of some “pipeline item” is in ParaView the attribute that is shown in a render view with coloring - direct or mapped.
If now a custom filter generates a new attribute, it would be nice if after pressing “Apply”, that attribute automatically becomes the one that is displayed in the render view with proper coloring accordingly. This is user friendly because he sees immediately what he has achieved.
However, adding a code line like at the end of a RequestData function does not seem to do the trick:
output->SetActiveScalars(TargetArrayName);
Meaning: it probably does set the TargetArrayName as the new “active scalar”, but somewhing seems to be still missing in order to really show it in the render view display!
And yes: That new attribute was of course added to the output “unstructured grid” before that call.
Thanks - this is good to know! So I will not even try from now on.
And sure: as a user I can choose the attribute to be shown through that attributes combo box in the toolbar.
However, which one is shown first after I press “Apply”, for filters that have the primary task to generate a new attribute. If I take the Calculator for example, it does exactly that: I calculate a new attribute and call it Result, this would be the attribute that is chosen in the combo box after pressing “Apply”. Then of course the user can choose to visualize something else.
And with this I see that I should probably have a very close look into the source code of the Calculator - or else find a less complex filter that has the same behaviour…
if (this->ResultTCoords || this->ResultNormals || !this->CoordinateResults)
{
resultArray->SetName(this->ResultArrayName);
outFD->AddArray(resultArray);
if (resultType == SCALAR_RESULT)
{
if (this->ResultTCoords)
{
outFD->SetActiveTCoords(this->ResultArrayName);
}
else
{
outFD->SetActiveScalars(this->ResultArrayName);
}
}
else
{
if (this->ResultTCoords || this->ResultNormals)
{
if (this->ResultTCoords)
{
outFD->SetActiveTCoords(this->ResultArrayName);
}
if (this->ResultNormals)
{
outFD->SetActiveNormals(this->ResultArrayName);
}
}
else
{
outFD->SetActiveVectors(this->ResultArrayName);
}
}
}
…which is indeed: Just call SetActiveScalars() or something comparable. With the only difference that other than in my own filter it is doing the trick here…
Some other filters that also generate a new attribute simply do not do it at all: There indeed the user is supposed to choose that attribute himself.
Meaning probably: Either give up on this idea, or try some “dirty hacks” - with always the danger of breaking with future versions of PV…
Besides the “Calculator”, I did not find other ParaView filters (yet) generating a new attribute and even doing the attempt to switch to that attribute after “Apply”. In these cases the user has to switch manually - after “recovering” from the first impression that the filter looks like it has not worked properly
From my own filters I had so far only the impression that “sometimes it works, sometimes not”. A more systematic test showed now that out of 7 filters, 5 actually worked the way I wanted just by calling the SetActiveScalars() function while 2 did not
The 2 filters that did not do the switching are those that are using customized property widgets, where from the widget code I am interacting with the selection manager in order to achieve certain not “officially” supported actions.
Bottom line: It looks like it is my own “fault” that the SetActiveScalars() function is not always doing what it seems to have done at least in the past - even though it is, as Mathieu points out, deprecated in VTK.
Since the fact that the function call is doing the job seems to be just “good luck” at the moment, I will have to decide whether I want to further dive into this subject and find out where it actually happens and how I can make it work also for the other filters.
However, this may not even be very much “future proof” if that function will eventually disappear from the VTK!
Thanks for this clarification - very important also for me! Because it means that I can try using it as long as I want. And the fact is that I consider this functionality as rather important for the “customer experience”, and I expect users to miss it if I would drop it.
Meaning specifically: If a filter generates a new attribute, either with a predefined name or with a name that the user specifies with some property, he somehow expects to see that attribute after pressing “Apply”! Otherwise it feels like the filter “has not worked” - even if the new attribute was correctly generated and is now available in the “Variables” combo box for selecting.
An important detail: This automatic switching occurs exactly once and not any more after the user has changed some properties and pressed “Apply” once more.
All this is exactly the behaviour of the “Calculator” filter, and I saw that it is done by calling the SetActiveScalars() function (or some similar ones if that fits better). However, I also see that with other ParaView filters the behavior is different and exactly the way how I do not want it to be - because of the reason explained above.
The following I write only for other programmers who would struggle with the same next question: How could an explicit switch be triggered after a later “Apply”?
In order to answer this question, I spent far too many hours digging in the codes of ParaView in order to find the place where the “magic” with this switching actually happens - with no success. The point is that from some property widget code I have to do an explicit “preparatory Apply call” in the background, before the user even has a chance to specify an attribute, so I would like to do the automatic switching during the second and not already the first call to RequestData(), but exactly for this I could not find a way how to achieve it!
The only way I could finally get it done is directly through the Qt widget itself: After finding the “Variables” combo box inside the pqColorToolbar object, I could directly call setCurrentText() in that combo box, thus “simulating” a user action.
This is of course not a safe way that will work with future versions of the software in the same way, but it turned out to be the only “emergency solution” that I was able to implement. And the good thing is that right now it works!
