Author Topic: Getting values of input properties of an sbsar graph returns default values  (Read 1654 times)

Hi, I am trying to retrieve current values of input parameters of an sbsar present into my current graph. It seems I am only getting the default values instead of the actual ones. I think this is a bug, can anyone please check/confirm? SD 2019.2.2

Code: [Select]
    @classmethod
    def logInputProperties(cls, graph):
        log("graph id=" + graph.getIdentifier())
        props = graph.getProperties(SDPropertyCategory.Input)
        psize = props.getSize()
        p = 0
        while p < psize:
            prop = props.getItem(p)
            propId = prop.getId()
            val = graph.getPropertyValue(prop)
            if isinstance(val, SDValueInt2):
                valInt2 = val.get()
                log(propId + " (int2): x=" + str(valInt2.x) + " y=" + str(valInt2.y))
            p += 1
Last Edit: October 30, 2019, 06:53:47 pm

Not seeing this issue on my end; although I'm having difficulty following your logic.

Quote
Hi, I am trying to retrieve current values of input parameters of an sbsar present into my current graph.
Your code on the other hand is attempting to get the property value from a graph.

1) How is this set up? Is this sbsar parameter you're querying exposed to the main graph? Or is it simply showing you the values of another parameter that happens to have the same id as the sbsar parameter?

2) To get the actual value from the sbsar, you'd need to query it from the node.
Code: [Select]
node.getProperties(SdPropertyCategory.Input)
...
node.getPropertyValue(prop).get()
Last Edit: October 30, 2019, 08:55:08 pm

1) How is this set up? Is this sbsar parameter you're querying exposed to the main graph? Or is it simply showing you the values of another parameter that happens to have the same id as the sbsar parameter?

This is an sbsar dragged&dropped from the Library into the current graph.

2) To get the actual value from the sbsar, you'd need to query it from the node.

Thanks! Indeed getting values from the node is working, but getting values from the graph being referenced by the node (node.getReferencedResource()) is returning the default values instead of the actual values. Setting property values into the graph object changes its default values, whereas setting property values into the node changes its current values. So things are consistent, I just didn't know it worked like this :)



Last Edit: October 31, 2019, 10:06:58 am

Quote
Indeed getting values from the node is working, but getting values from the graph being referenced by the node (node.getReferencedResource()) is returning the default values instead of the actual values
In this case both "default" values and "actual" values are the same. Once you save a graph, those values become the "default/actual" values.

Quote
Setting property values into the graph object changes its default values, whereas setting property values into the node changes its current values. So things are consistent, I just didn't know it worked like this
Something along those lines.
For clarification; when you reference that graph into another one, the overrides for any parameters on the referenced graph, always belong to the node in the parent graph.

Example:

pkg_a
  graph_a
   parameters:
     - param_x: 1
     - param_y: 2

pkg_b
  graph_b
    instances (nodes):

      node_a (sbsar instance of pkg_a.graph_a)
       graph_a
         parameters:

           - param_x: 1 --> 10    #Default 1 still belongs to pkg_a.graph_a, but the override of 10 now belongs to pkg_b.graph_b.node_a.
           - param_y: 2 --> 5    #Default 2 still belongs to pkg_a.graph_a, but the override of 5 now belongs to pkg_b.graph_b.node_a.

Quote
Indeed getting values from the node is working, but getting values from the graph being referenced by the node (node.getReferencedResource()) is returning the default values instead of the actual values
In this case both "default" values and "actual" values are the same.

Not sure what you mean by "the same" here, as in practice they are not the same. I.e. with the following scenario:
- drag&drop sbsar in current graph
- click on sbsar to display its properties, notice default value for a given integer input param is 1
- change this value to 5 manually

now, using the Python API:
- access the sbsar SDNode by parsing the current graph, get the property value for the integer we modified, we get 5.
- access the sbsar SDGraph from the node (being SDNode.getReferencedResrouce()), get the property value for the integer we modified, we get 1.


Last Edit: October 31, 2019, 03:44:52 pm

Quote
...but getting values from the graph being referenced by the node (node.getReferencedResource()) is returning the default values instead of the actual values

So in your example you used node.getReferencedResource() which will most likely return a SDSBSCompGraph object.
This is returning an instance of the graph from the source (sbsar). This source does not have the overrides since the overrides belong to the node.

When the node is created it is simply a representation of the last saved state of the graph. Any overrides you apply to the node, belong to the node, not the graph it was created from.



Maybe it's bad wording on my part, so let me try it this way:
- You're working on pkg_a.graph_a and set your parameters (x=1, y=2). These parameters are recognized as default values.
- You reference pkg_a.graph_a into pkg_b.graph_b, it is now known as node_a. (at this point you haven't applied overrides)
- You query these parameters from node_a and you get x=1, y=2. These are your actual values ONLY in pkg_b, inherited from pkg_a.
- You override these parameters in pkg_b.graph_b.node_a to x=10, y=5. These are your actual values ONLY in pkg_b.
- You query these parameters from node_a again, this time you get x=10, y=5. Still actual values in  pkg_b.



Quote
- access the sbsar SDNode by parsing the current graph, get the property value for the integer we modified, we get 5.
When you query them using node_a.getPropertyValue(), you're getting the correct values because you're querying them from the pkg_b.graph_b.node_a, which is the source of these overrides.

Quote
- access the sbsar SDGraph from the node (being SDNode.getReferencedResrouce()), get the property value for the integer we modified, we get 1.
When you query these parameters using node.getReferencedResoruce(), you get x=1, y=2. This is because you're actually querying them from pkg_a.graph_a, instead of pkg_b.graph_b.node_a.



The overrides you applied in pkg_b.graph_b.node_a belong to node_a.
GetReferencedResource() returns the source of your reference (pkg_a.graph_a), which is in a totally different context than the graph you're currently manipulating (pkg_b.graph_b).
Last Edit: October 31, 2019, 04:29:17 pm

Yes, your explanations make sense, I was just commenting on "In this case both "default" values and "actual" values are the same". Thanks again for your help!

I noticed we can also set values into the sbsar referenced graph and these are taken as default values (i.e. when using "Reset to default" menu on instance parameters, these show up). I am not sure why this is enabled as this is rather "dangerous", we are not supposed to modify the defaults of an sbsar which should be read-only I guess.

I noticed we can also set values into the sbsar referenced graph and these are taken as default values (i.e. when using "Reset to default" menu on instance parameters, these show up). I am not sure why this is enabled as this is rather "dangerous", we are not supposed to modify the defaults of an sbsar which should be read-only I guess.
When you're modifying the default value via node.getReferencedResource().setPropertyValue(), correct?

Interesting, I just looked into this and it does appear to be changing the default values.

However, it does not save these changes to the source package unless you explicitly tell it to. Or in the case of sbsar's, I'm not even sure if you can.

What it appears to be doing instead is creating a cached version of that package that gets used for the duration of your Designer session.
If you re-launch your Designer session, the properties will go back to the default values that were in the package file itself.

I'm not sure what the point is in allowing the user to do this.
I agree this is unpredictable behavior, can be potentially dangerous and should probably not be implemented the way it currently is.
Ideally it should be a read only SDCompGraph representation with all the set methods stripped out.
Last Edit: October 31, 2019, 05:36:32 pm

When you're modifying the default value via node.getReferencedResource().setPropertyValue(), correct?

Yes. Even if we cannot save it, that should not be allowed, we can enable hidden properties this way that should be read-only. I will submit a bug report.