Failed to locate property... - Issue on porting from 5.5 to 5.6 rc2

Development
1

I am right now porting my “custom application” from being based on PV 5.5.0 to PV 5.6.0-RC2. Now I have a crash if I change the color coding for a render view by selecting another attribute from the combo box.

I don’t have the crash if I simply load the same “unstructured grid” into plain PV v5.6.0-RC2, so there is now some discrepancy between the updated “PV base” and my own custom code, and from all my research so far I found out that there must be some vtkContext2DScalarBarActor that has now a new property named “ReverseLegend” that did not exist in the old version yet.

Of course my custom application has a modified “main window” class that started being a clone of the paraview main window class and is now customized. For the rest there is not much code copied and adapted, mostly just added, so I am a bit lost where I should handle this new property. But with some “diff” tool I also do not see too many differences between ParaviewMainWindow.cxx at v5.5.0 and v5.6.0-RC2.

Shortly before the crash the output window appears, but does not show a message yet. With the debugger I could see what the intended message actually was:

Warning: In C:\dev\pv\src\ParaViewCore\ServerManager\Core\vtkSMProxy.cxx, line 1705\vtkSMScalarBarWidgetRepresentationProxy (000001E866613310): Failed to locate property ‘ReverseLegend’ on subproxy ‘Prop2DActor’: ScalarBarWidgetRepresentation

And the crash actually happens at vtkSMNewWidgetRepresentationProxy.cxx(181) - where obviously some property (“prop”) was not found and then the null pointer was used in line 181 without further checking. The call stack from the “index changed” signal from the combo box to the point where the message should be emitted is:

1 vtkSMProxy::SetupExposedProperty vtkSMProxy.cxx 1705 0x7ffdc3517d95
2 vtkSMProxy::SetupExposedProperties vtkSMProxy.cxx 1777 0x7ffdc3514e9a
3 vtkSMProxy::CreateSubProxiesAndProperties vtkSMProxy.cxx 1627 0x7ffdc35166a0
4 vtkSMProxy::ReadXMLAttributes vtkSMProxy.cxx 1513 0x7ffdc3514861
5 vtkSMSessionProxyManager::NewProxy vtkSMSessionProxyManager.cxx 338 0x7ffdc35d1549
6 vtkSMSessionProxyManager::NewProxy vtkSMSessionProxyManager.cxx 312 0x7ffdc35c955c
7 vtkSMTransferFunctionManager::GetScalarBarRepresentation vtkSMTransferFunctionManager.cxx 196 0x7ffdbc433de0
8 vtkSMPVRepresentationProxy::SetScalarBarVisibility vtkSMPVRepresentationProxy.cxx 682 0x7ffdbc3caf49
9 vtkSMPVRepresentationProxy::SetScalarBarVisibility vtkSMPVRepresentationProxy.h 250 0x7ffdbc3d2bfd
10 pqDisplayColorWidget::PropertyLinksConnection::setServerManagerValue pqDisplayColorWidget.cxx 183 0x7ffdc9095601
11 pqPropertyLinksConnection::copyValuesFromQtToServerManager pqPropertyLinksConnection.cxx 296 0x7ffdc3b13d00
12 pqPropertyLinks::onQtPropertyModified pqPropertyLinks.cxx 159 0x7ffdc3b0bd79
13 pqPropertyLinks::qt_static_metacall moc_pqPropertyLinks.cpp 115 0x7ffdc3ba3566
14 QMetaObject::activate qobject.cpp 3768 0x58db5d1a
15 QMetaObject::activate qobject.cpp 3629 0x58db5488
16 pqPropertyLinksConnection::qtpropertyModified moc_pqPropertyLinksConnection.cpp 153 0x7ffdc3ba3156
17 pqPropertyLinksConnection::qt_static_metacall moc_pqPropertyLinksConnection.cpp 87 0x7ffdc3ba3051
18 QMetaObject::activate qobject.cpp 3768 0x58db5d1a
19 QMetaObject::activate qobject.cpp 3629 0x58db5488
20 pqDisplayColorWidget::arraySelectionChanged moc_pqDisplayColorWidget.cpp 166 0x7ffdc9307526
21 pqDisplayColorWidget::qt_static_metacall moc_pqDisplayColorWidget.cpp 103 0x7ffdc93073b6
22 QMetaObject::activate qobject.cpp 3768 0x58db5d1a
23 QMetaObject::activate qobject.cpp 3629 0x58db5488
24 QComboBox::currentIndexChanged moc_qcombobox.cpp 505 0x597402ad

Debugging possible missing or wrong signal/slot connections can be hard, and the same is true for the “properties” system of Paraview.

So I would be glad with the one or other “educated guess” from experts!

2

Solved! But it was indeed hairy…

In order to change one little setting (the number format for the legend min/max labels) that is defined in utilities.xml I had to copy the entire segment from there into an own xml. But now in the new version of PV, this new “ReverseLegend” property needed to be added there as well - and because it wasn’t I was running into the described troubles…

So indeed debugging these “properties” can be tough, but with the aid of grep and some git diff the case could finally be solved.

3

Have you tried using custom application settings to change property, instead of redefining the proxy? During initialization of your app, you can call vtkSMSettings::AddCollectionFromString, for example, to load a custom json to that can override property defaults. When creating that proxy, those defaults are loaded (with a few exceptions). The json would look something like follows

{
"representations" :
  {
    "ScalarBarWidgetRepresentation" :
    {
      "AutomaticLabelFormat" : 0,
      "RangeLabelFormat" : "%f",
    }
  },   
}
4

Thanks for the hint!

However, I tried such things already before without success. Now I tried again at the end of my main constructor:

// change the number representation of the scalar bar widget
// (and hope it is the color legend bar of the render view...)
settings->AddCollectionFromString("{ \"representations\" : { "
                                  "\"ScalarBarWidgetRepresentation\" : { "
                                  "\"AutomaticLabelFormat\" : \"0\", "
                                  "\"RangeLabelFormat\" : \"%.4f\", "
                                  "\"LabelFormat\" : \"%.4f\" } }, }",
                                  10.0);

But there was no change in the appearance of the numbers in the color legend bar in the render view - which is the purpose of the whole exercise. (No, I do not want 4 digits, but I wanted to try “something visible” for the test!)

Actually I don’t know what the “scalar bar widget” is - maybe the thing that I am talking about? But also maybe something different - and just happened to be the item where my crash occurred (my initial problem here).

However, I would still prefer this kind of solution because it is less intrusive, more elegant, the method of redefining the entire proxy was so far for me the only thing that really did the trick! :wink:

5

Sorry, I was wrong in my previous post: just dropping the second last comma in the second last line changed the JSON to something “legal” - and with this I actually got the effect that I wanted!

So thanks again, and I am kicking out this xml now from my code because this is definitely more elegant. (And maybe it helps also to avoid “strange errors” during future updates…)

More precisely: I see no effect of the “AutomaticLabelFormat” and the “LabelFormat” settings, but the “RangeLabelFormat” is actually the one that I really want - and this works!