If I create a BindableElement, bind it, and register a callback, the callback is invoked before the value is written to either the SerializedObject or the target.
This means that code I invoke in that callback can’t just assume that the value I set is correct. I have to either send the result I get from evt.newValue everywhere, or manually write the value into the field (which kinda defeats the entire purpose of the binding!).
In my bug report (and our real project), we have a controller script that drives the properties of a bunch of child Sprite Renderers. One of those is the sorting layer. So if you add a SpriteRenderer as a child of this script’s transform, we automatically set the sorting layer on the children. The same thing goes for some material settings and some other stuff.
So I added a change event to the popup that shows all of the layers, and then I just called the same method that I usually do to update all children. But, nope, that won’t work, because the value is outdated.
I’ll post the bug report # when the bug goes through - taking longer than usual today.
Hello, this is working as designed (though it doesn’t mean the design is wrong, just means it’s expected as it is right now). There’s a reason for it that I’m trying to find and will try to report back when I have it (I have an idea but I’m one of the new people in the team and missed lots of key decisions so don’t want to be imprecise).
In any case, what you can do in this case is to use schedule.Execute which will delay the running of your logic to after the bound value is updated. You can also set your field as isDelayed to only apply the value after the change is done (user presses enters/focus is lost). The inspector for UIDocument works like that for the sort order field, for example.
I mean, thanks for the answer, but the situation where it’s absolutely random if something happens based on how long my code takes to execute is bonkers.
So, yeah, you really need to address this. I get that there’s a time pressure now to get things out, but I’m up to my hip in UI Toolkit bugs and issues, and getting “race conditions is expected behaviour” in my lap isn’t exactly great.
Uff, I’m looking to get into the new UI Toolkit atm, but I get the same vibes as you describe for the Addressables package right now. Maybe I sould just turn the spot for better :s
So sorry about that, I confused myself. I have a different bug report that’s about a race condition in UI Toolkit, and for some reason I thought this thread was about that one.
This thread is about #1321156, while I was talking about #1320552.
I’ll re-read the post you linked, now with the correct context. There’s been quite a few UI Toolkit bugs lately, so I get them mixed up.