API that returns true if a scrollbar is hovered?

[sodamouse]

Version/Branch of Dear ImGui:

Version 1.91.5, Branch: docking

Back-ends:

imgui_impl_opengl3.cpp + imgui_impl_glfw.cpp

Compiler, OS:

Windows 11 + MSVC 2022

Full config/build information:

No response

Details:

My Issue/Question:

Hi, I've implemented the following to highlight a table's rows if it is currently being hovered:

ImGuiContext& g   = *ImGui::GetCurrentContext();
ImGuiTable* table = g.CurrentTable;

ImRect rect(table->WorkRect.Min.x, table->RowPosY1, table->WorkRect.Max.x, table->RowPosY2);

bool hover =
    ImGui::IsMouseHoveringRect(rect.Min, rect.Max, false) &&
    ImGui::IsWindowHovered(ImGuiHoveredFlags_None)
;

static constexpr auto SAYVE_COL32_TABLE_HIGHLIGHT = IM_COL32(255,255,255,64);

if (hover)
{
    ImGui::GetForegroundDrawList()->AddRectFilled(
        {rect.Min.x, rect.Min.y},
        {rect.Max.x, rect.Max.y},
        SAYVE_COL32_TABLE_HIGHLIGHT
    );
}

This works really well, except for the case where the OS layer window that holds the application is small, causing the horizontal scrollbar to be drawn. This produces the visual clash shown below:

The scrollbar is still interactible and functional, but obviously the visual effect is not nice.

I am looking for ideas on how to solve this problem. I was thinking that an API call that would return true if the scroll bar is hovered would solve my problem, but there might be another way to solve this already. Any suggestions are welcome.

[ocornut]

Hi, I've implemented the following to highlight a table's rows if it is currently being hovered:

FYI you may also submit a Selectable() with the ImGuiSelectableFlags_SpanAllColumns | ImGuiSelectableFlags_AllowOverlap flag.

You may also use ImGuiTableFlags_HighlightHoveredColumn for column but I am thinking we could add the equivalent ImGuiTableFlags_HighlightHoveredRow helper.

The scrollbar is still interactible and functional, but obviously the visual effect is not nice.

Well you are drawing into GetForegroundDrawList() which is front of everything so naturally it is in front of the scrollbar.
You should probably draw into the current draw list instead... GetWindowDrawList(), where the right clipping rectangle will be set

I am looking for ideas on how to solve this problem. I was thinking that an API call that would return true if the scroll bar is hovered would solve my problem, but there might be another way to solve this already. Any suggestions are welcome.

This is a XY Problem at this point so it is not worth answering the "is scrollbar hovered" part of the question. Rather draw into the correct draw list.

[sodamouse]

Hi @ocornut, I had actually tried GetWindowDrawList, but this doesn't actually resolve my issue, because if you have InputText fields, then the highlight does not apply over, but under.

I will try the selectable suggestion instead of my approach to see if it produces the exact effect I want.

Edit - I am thinking that I'm not using the draw lists correctly. I use the same highlighting technique in multiple applications and switching to GetWindowDrawList produces inconsistent results across codebases. For example in the picture here the buttons are underneath the highlight whereas the textinputs are not, but in another project most elements are on top.

[sodamouse]

Also this helper would be useful to me, just wanted to mention:
ImGuiTableFlags_HighlightHoveredRow

[ocornut]

then the highlight does not apply over, but under.

Within a same window, things are rendered in the order they are submitted.

[sodamouse]

That makes sense, but in this case the highlight is the last thing that is being submitted.

I am drawing stuff in a for loop:

for (loop)
{
    // draw a bunch of ImGui stuff
    // The highlighting code from first post.
}

[ocornut]

If child windows are involved they are drawn above their parent.
Otherwise i suspect you are making a mistake somewhere.

ah! Maybe it is related to draw call merging in the table api!
Columns draw call are merged based on their contents. That would explain the inconsistencies. See what SpanAllColumns is doing, pushing a cliprect and draw channel that is not part of the main column draw channel.

[sodamouse]

Yeah I think that's the issue here