Widget ID == Label #647
Comments
|
or use the ## to add a invisible label. In other words have the label string be |
|
Thanks ratchetfreak. I would never have guessed that "##" and "###" substrings had some special meaning w.r.t. IDs. It is good to know this exists, but I still think it is bad API design to have the ID be hidden in the label string. My suggestion of having a separate, optional, ID argument would make the ID more explicit in the API and more discoverable. It would be obvious how the function works by looking at its definition in the header instead of relying on an FAQ. If people are asking frequently, maybe it is confusing. |
|
It's all in the FAQ. Maybe the FAQ has to be prominent. There's also a concept of id stack. You think it is bad api design I think it is a perfectly elegant and functional idea to do that. We're not going to add an extra parameter to EVERY function to cover an uncommon case. You can instead mix up "##blah" and SameLine/Text stuff to combine elements. I'd advise against trying to aim for a label-on-the-left-widget-on-the-right layout style. There's a set if layout options in the work to allow it automatically on all widgets but it has many less benefits than the opposite in term of layout flexibility. |
|
For the record I agree it would be more discoverable to have explicit two parameters, but an API is also about being practical and efficient. Trading discoverability for a forever heavier-api not always worth it. Once you get how this works in ImGui then you are set. Note however that eg this is exactly what the TreeNode API is doing, we have variants taking an ID + a format string to display that is independant from the ID. All those micro choices are also decided because of c++ constraints (eg: if c++ could allow the user to reasonably format string or pass slices to any functions then we wouldnt have format string parameters in the api. Alas c++ is pretty much a shitty language!) |
Also #74, #96, #480, #501, #647, #654, #719, #843, #894, #1057, #1173, #1390, #1414, #1556, #1768, #2041, #2116, #2330, #2475, #2562, #2667, #2807, #2885, #3102, #3375, #3526, #3964, #4008, #4070, #4158, #4172, #4199, #4375, #4395, #4471, #4548, #4612, #4631, #4657, #4796, #5210, #5303, #5360, #5393, #5533, #5692, #5707, #5729, #5773, #5787, #5884, #6046, #6093, #6186, #6223, #6364, #6387, #6567, #6692, #6724, #6939, #6984, #7246, #7270, #7375, #7421, #7434, #7472, #7581, #7724, #7926, #7937 and probably more.. Tagging to increase visibility!
The widget ID seems to be the same thing as the label. Maybe I'm missing something, but this seems to mean that I can't use inputs without a label, because if I set all of the inputs to have the empty label string
"", then they all get selected and interfere with each other. I'm getting around this by just deleting the code that displays a label within the widget.Maybe the best solution is to add an optional ID field that will be used for the ID instead of the label when supplied? Maybe get rid of the label entirely like I did, and rely on the user calling
SameLine();Text("label");to get the label? Actually this second option sounds surprisingly reasonable to me, because they there is a possibility to put the label in front of the text also.The text was updated successfully, but these errors were encountered: