ImGui::BeginTooltip() should allow specifying override about imgui

[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 :)