-
-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DragFloatRange2 and DragIntRange2 fail to check bounds #1441
Comments
Ouch, this is quite an issue. It's a little delicate to fix because DragFloat() signature basically says that when v_min==v_max there's no bound. So we'd need to fix that, and probably switch to using -FLT_MAX..FLT_MAX as default values, but it makes DragFloat() less welcoming when you want to fill in the extra parameters (also I wonder if all languages have access to a reliable version of FLT_MAX). The other solution would be to make that change only in an internal version DragFloatEx() which is wrapped by DragFloat() with a translation of v_min==v_max to -FLT_MAX,FLT_MAX, and then the DragFloatRange2() can use this function directly. I think I prefer the second solution as it won't break user code, and we can always morph the second solution into the first one later if we want to. Added reference to #76 |
…f bounds when both min and max value are on the same value. (#1441)
…f bounds when both min and max value are on the same value. (ocornut#1441)
There is a bug in both of these, which makes it to not respect the bounds set by v_min and v_max parameters.
Repro
Now Min widget no longer respects the v_min and v_max parameters, you can drag it negative percents (below v_min), over the current max value and over v_max. You can do it also the other way around: drag the min value all the way to v_max, and then the current max no longer respects the bounds.
You can observe the same behavior in DragIntRange2 - but not in the ImGui demo, of course ;)
Edit: version 1.52
The text was updated successfully, but these errors were encountered: