Highlighting Changing of a Sub-Sub-Property

[bjoernTWK]

If a Sub-Property is placed under a ModeTypeProperty and the value is changed via a calculator, the property is not highlighted

[jensschmeink]

@bjoernTWK do you have an example or a screenshot? That could help to find the problem

[bjoernTWK]

@bjoernTWK do you have an example or a screenshot? That could help to find the problem

I have no screenshot for this behavior. Is it not possible to re-produce the issue (or is there another reason for the request)?

[jensschmeink]

Just to reproduce the error faster.

[jensschmeink]

This problem might be related to the issue #191

[rainman110]

@bjoernTWK please provide a specific example. I don't yet understand, how the properties need to be arranged.

[bjoernTWK]

As an example I've choosen the VGVcompressor:

• [ ] before run -[ ] after run

[bjoernTWK]

@rainman110 I hope this example is helpful

[rainman110]

@bjoernTWK I did an analysis of the problem.

The reason is the following. GTlab is currently sensitive on the order of the registration of properties and subproperties. In particular, subproperties need to be registered, before the main property is registered to the object.

In this case in the Performance Module, the order is incorrect, the main property in registered too early and need to be fixed there.

Here's a best practice on how to register properties:

• First, register all subProperties via GtAbstractProperty::registerSubProperty on the constructor

• At the end of the constructor, register the remaining main properties via GtObject::registerProperty

  I know this is a nasty behavior of GTlab, but this is currently how it works in the 2.0.X series as we cannot change the property signaling logic in a patch release.

I will create an issue for the 2.1 release series, that we change the way, how subproperties change signals are escalated to the top, such that the order of registering does not matter anymore.