2_Sliders.tox (8.8 KB)
Here we got two practically identical custom made slider components. The only difference of them is the bindCHOP inputs order. Component on the left got its slider kinda stuck from time to time if you move cursor from the slider panel
Order in bindCHOP obviously shouldnt affect the UI behaviour in the presented case.
+1
The issue becomes directly apparent when trying to drag on the left slider quickly, it will often not go all the way to 100%. The right slider always works properly.
Jonas
WV
Thanks for the report.
I was able to reproduce and this is logged for a developer to look into it.
Best,
Michel
Okay we did a little dive on this and it’s a classic UI problem. In a nutshell, the problem is that there’s a race condition between the two inputs to the bindCHOP when the 2 values change on the same frame. Because the lower input takes priority, the order matters, thus the unexpected difference. This particular manifestation is because the clamped panel value stops changing once you go outside the limit, but the bindCHOP is stuck on the par value which is one frame behind.
While you can solve the problem by ordering the bindCHOP inputs differently like in the example, I think the more graceful solution here is to keep your ui value (u) more separate from your data (Value). I built an example.
3_sliders.toe (7.7 KB)
