I have a custom property named Trigger that I use to trigger a propertyChange script.
At the end of the script I set the property to 0, but it looks like the value is not actually being set.
Debug Log:
The property is set to zero eventually, but not being set at the end is causing the script to run twice.
Any ideas on how to fix?
Show your entire script.
But keep in mind that assigning to a Vision component property causes that property's change event to fire right there, recursively if called from within that event script.
The script is running twice because you're changing the property from within a property change script. The end of the script causes a property change, and then that property change causes it to run again.
and the complete Debug for this:
I expected that the propertyChange script would run twice, I just expected that the value of the Property would have updated.
Also annoyed that I misspelled "Parrent" in my debugging.
Try print event.newValue, event.source.Trigger.
The reliable new value in recursion is in event.newValue. Consider adding that to your print at the top of your script. Consider also using single print statements.
For a simpler demonstration, make a temporary component and add a custom integer property Test, then add this change event:
if event.propertyName == 'Test':
print "Pre:", event.newValue, event.source.Test
if event.newValue < 5:
nextValue = event.newValue + 1
event.source.Test = nextValue
print "Post:", nextValue, event.source.Test
Put your designer in preview, and alter that property to some number < 5. Look at the console output.
Do I need to create a new Property named newValue? I am getting errors when I try to run.
Thanks for the help!!!
Looks like I need to add some code that verifies that newValue and Property's value match. Or maybe just run the script on the newValue.
Also thanks for the hint on the print statement. I did not realize that I could add comments between values.
This.
The key insight is that property change events can sometimes happen before the property is "latched". Ideally, this would be consistently either before or after, but between fifteen years of our own component development and the underlying system (Java Swing) I can guarantee that it's not; different properties on different components (or even the same component) will fire before or after the property has actually 'latched' and will reflect the new value when it is next read.
As Phil said - the only safe bet is to rely on event.newValue.
Somewhat confusingly, what's actually happening is when you say
print x, y
You're creating a tuple (x, y) and passing that to print. 99% of the time this doesn't matter and it just does what you want, but it's a potentially useful bit of trivia.
