-
-
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
New feature: default number for empty float field. #7305
Comments
I don't think realistically we would accept a PR adding an extra parameter to those frequently-called-and-already-long-signatures functions. However:
(PS: 1.83 will soon be 3 years ago, and is 2000+ lines down in the changelog, I would suggest updating :) |
something like
?
I'm forking an existing project, so I tend to not update the library before the main branch do it. Edit: also, is it possible to pass the default value (here 0) via ImGuiNextItemData ? |
I don't fancy this a lot and the names would need to be more self-explanatory, but at least if you go this way your patch will touch much less code and will be easier to merge.
You don't need to call it if the buffer is empty, it makes sense to apply your logic in the caller code.
In theory yes by storing it into an opaque ImGuiDataType + ImGuiDataTypeTempStorage and adding the corresponding _HasFlag, but I need you can solve your need with less changes by creating your copy of InputScalar(). |
something like that so? I'm not really sure of what I'll be using. maybe I will need another default value than 0 (like FLOAT_MAX or -1, and i set any invalid value to that). So I'll wait to let it settle. |
Yes, but I think your Now your patch becomes short and easy to maintain. |
I am going to try to work on finishing that. I believe two separate flags are preferable, as in some instances user may want to parse empty as zero/default but still display the editable value. IMHO the issue with your previous version was the names were a little ambiguous. My answer was also ambiguous ("I don't fancy this a lot and the names would...") I believe I may have intended to suggest that only the names was as a problem (maybe I mistyped "I don't fancy this a lot AS the names would" ?), because presently I don't see an issue with the idea itself. First suggestion: ImGuiInputTextFlags_ParseEmptyAsZero
ImGuiInputTextFlags_DisplayZeroAsEmpty or preferably ImGuiInputTextFlags_ParseEmptyAsDefault
ImGuiInputTextFlags_DisplayDefaultAsEmpty I also considered: ImGuiInputTextFlags_ParseEmptyAsRefValue
ImGuiInputTextFlags_DisplayRefValueAsEmpty But somehow "Default" seems simpler. It won't be costly to add a new field in NextItemData, so even if we don't expose it publicly you may use it. This kind of advanced use is usually used in high-level functions and easy to wrap anyhow. Therefore it seems sane to use the 'Default' terminology rather than 'Zero'. Note that coincidentally as your last patch uses 'Default' as a verb ( |
I realize one ambiguity for the user would be to parse an empty field as 0.0/default, but not update underlying value on "invalid" input. |
…tyRefVal, ImGuiInputTextFlags_DisplayEmptyRefVal. (#7305)
I went back and forth and ended up calling them: I also added the necessary data in NextItemData, but there's no public static-typed accessor for it.
|
Version/Branch of Dear ImGui:
1.83
Back-ends:
don't know, the cpp library
Compiler, OS:
windows (visual), linux, macos
Full config/build information:
No response
Details:
Hi
I wanted to change the behavior, so when the user erase the content of an input the value return to a default value instead of not changing.
And also to not draw anything when the value is the default.
Here is apatch for the feature (for float field only):
If it's something you want, I can devote a little time to create a pr to have the default for all types, and maybe a way to activate the value hiding separately.
An exemple of the end result (with a min set and a max at default value, ie not set by the user):
Screenshots/Video:
No response
Minimal, Complete and Verifiable Example code:
The text was updated successfully, but these errors were encountered: