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!