ImGui::BeginTooltip() should allow specifying override

[DanielGibson]

Version/Branch of Dear ImGui:

1.90.6

Back-ends:

All

Compiler, OS:

All

Full config/build information:

No response

Details:

ImGui::BeginTooltipEx() (which is only available through imgui_internal.h) allows specifying if one wants to override a current tooltip or, which is the default, extend it.

The regular ImGui::BeginTooltip() always extends existing tooltips, while the (also publicly exposed) ImGui::SetTooltip() always sets the override flag (which BTW is contradicting to the documentation/comments, which says "SetTooltip() is a shortcut for the 'if (BeginTooltip()) { Text(...); EndTooltip(); }' idiom.").

I think it would be useful if one could specify if an existing tooltip should be overridden or if it should be extended.

This could be done without breaking API-backwards-compat with
bool BeginTooltip( bool overridePrevious = false )
or by moving ImGuiTooltipFlags to the public imgui.h and using
bool BeginTooltip( ImGuiTooltipFlags = ImGuiTooltipFlags_None )

For SetToolTip() this might also be useful, but there it can't be done without breaking the API, because of the varargs.

---

By the way, the text above says

Ask any question, discuss best practices, report a bug, request a feature. If this doesn't look right, choose a different type.

but as far as I can tell there is no way to choose a different type (Feature Request would probably be more appropriate), only this issue form.

Screenshots/Video:

No response

Minimal, Complete and Verifiable Example code:

No response

[ocornut]

but as far as I can tell there is no way to choose a different type (Feature Request would probably be more appropriate), only this issue form.

This text is generated by github and not part of issue form. It’s strange they are displaying it even when there’s a single template.
I think templates are too rigid, I am happy to keep a single open-ended one.

[DanielGibson]

This text is generated by github and not part of issue form. It’s strange they are displaying it even when there’s a single template.

The Microsoft UI team strikes again!

[ocornut]

We had a bunch of design and work done in November 2021 toward reworking tooltip API.
Some of it evolved into the hover delay, SetItemTooltip(), ImGuiHoveredFlags_ForTooltip of 1.89.7 and 1.90

But several things went stale, among them moving flags to public space, added named priority levels, making BeginTooltip() bool actually return false (it currently always return true). For SetTooltipXXX functions making flag the first parameter seemed like a possible workaround to the vaarg problem but I wasn't sure it was worth it.

I believe the priority level should be a better solution that the manipulation of the override flag, which is order dependent.

For references the WIP priority flags we came with were:

ImGuiTooltipFlags_PriorityHint      = 1 << 13,  // Low-priority "nice to have" tooltips, generally pushed by low-level, reusable widgets
ImGuiTooltipFlags_PriorityNormal    = 2 << 13,  // Regular tooltips (default)
ImGuiTooltipFlags_PriorityDrag      = 3 << 13,  // Dragged contents preview
ImGuiTooltipFlags_PriorityDrop      = 4 << 13,  // Messages from drop targets (e.g. "Cannot move node into a child of itself!")

TL;DR; this is work and progress and quite low priority at this point, and I would encourage you to use BeginTooltipEx() + the flag if needed. I will adjust the comment.

[DanielGibson]

Ok, thanks for the advice :)