I have a situation, where I have 2 internal properties, with the relevant setter/getter functions (say _a + aChanged, _b and bChanged).
Each setter calls invalidateProperties if the value has changed.
Now, the problem is that during the commitProperties, when handling the change for property a, I have to update the value of property b.
There are a few ways to do that:
1. Change the private member _b, and synthetically raise the bChanged flag.
This feels like a hack, and implies that the order of changes handling in the commitProperties function is important, since now I have to handle bChanged after I handle aChanged.
2. Call the setter for b with the new value and have it update on the next frame, since it's setter raises the invalidateProperties flag.
3. Eliminate the dependency by replacing the 2 variables with a single one.
2 seems like the better choice right? Wrong!!
Digging into the code, I saw that the UIComponent code for invalidateProperties simply sets the invalidatePropertiesFlag to true, the commitProperties code does nothing with it, and it also implements a public function called validateProperties, and here is the catch - it first calls commitProperties and ONLY THEN sets invalidatePropertiesFlag to false.
This means, that even if I call b setter and it in turn calls invalidateProperties (implicitly sets the invalidatePropertiesFlag to false), I can't rely on it being picked up next frame or any other time for that matter, since once the current commitProperties ends, the invalidatePropertiesFlag flag is set to false again.
It really buffles me why Adobe decided to implement validateProperties like this, especially considering that had they implemented it to first set the flag value to false and only then call commitProperties, this whole thing would be avoided...
I attached a simple example that shows this.