I have an expression structure that seems to be triggering the script under a transform multiple times.
I have the 'Wait On All' option selected, but if I do a print on all of the members in the structure, you can see the changes in the structure over the multiple executions. I am assuming the option would fire one change on the data structure for the binding, but it doesn't look like it is.
I'm building the parameters in a parent view and setting the parameters through scripting.
self.getChild("fcMain").getChild("imgTray").getChild("EmbeddedView_"+str(zoneId)).props.params = params
This is running only once. But it looks like the binding is firing multiple times as an array and list is getting populated/changed in the binding.
Am I wrong in my 'Wait on All' assumption? Do I just change my approach and avoid the expression structure?
I think your understanding of what 'Wait on All' does is flawed.
'Wait on All' just means that on initial startup of the binding, no intermediate values will be delivered to the rest of the system, during the transition from "uncertain, initial state" to "some actual value delivered by tag or property reference".
Think of it the other way around; how would a given expression structure binding "know" that all of its children are ready at the same time? It's actually a desirable behavior, in the vast majority of circumstances, for the expression structure binding to re-evaluate itself every time any of its children change.
In your particular case, I think you want a single property change event (on whichever property you consider to be the "driver") that collects the other properties via script. Or you could even have multiple property change scripts, and then you are in charge of the logic for "how often do I fire events as multiple things change".
1 Like
Thanks for the explanation. I already switched to a single property and everything works as expected now.
One thing to note incase someone else finds this topic, I thought writing to an object with multiple properties as a whole would get around the issue, but the binding still evaluates each individual expression at different times. Even if the expressions are all referencing properties in that same object.