Skip to content
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

Focused window pushed into the background by tooltips of other windows #7354

Closed
GamingMinds-DanielC opened this issue Feb 27, 2024 · 3 comments

Comments

@GamingMinds-DanielC
Copy link
Contributor

Version/Branch of Dear ImGui:

Version 1.90.4 WIP, Branch: docking

Back-ends:

imgui_impl_win32.cpp + imgui_impl_dx11/dx12.cpp

Compiler, OS:

Windows 10/11 + MSVC 2019/2022

Full config/build information:

Dear ImGui 1.90.4 WIP (19032)
--------------------------------
sizeof(size_t): 8, sizeof(ImDrawIdx): 2, sizeof(ImDrawVert): 20
define: __cplusplus=199711
define: _WIN32
define: _WIN64
define: _MSC_VER=1929
define: _MSVC_LANG=201703
define: IMGUI_HAS_VIEWPORT
define: IMGUI_HAS_DOCK
--------------------------------
io.BackendPlatformName: imgui_impl_win32
io.BackendRendererName: imgui_impl_dx11
io.ConfigFlags: 0x0000C441
 NavEnableKeyboard
 DockingEnable
 ViewportsEnable
 DpiEnableScaleViewports
 DpiEnableScaleFonts
io.ConfigViewportsNoDecoration
io.ConfigInputTextCursorBlink
io.ConfigWindowsResizeFromEdges
io.ConfigMemoryCompactTimer = 60.0
io.BackendFlags: 0x00001C0E
 HasMouseCursors
 HasSetMousePos
 PlatformHasViewports
 HasMouseHoveredViewport
 RendererHasVtxOffset
 RendererHasViewports
--------------------------------
io.Fonts: 1 fonts, Flags: 0x00000000, TexSize: 512,64
io.DisplaySize: 1264.00,761.00
io.DisplayFramebufferScale: 1.00,1.00
--------------------------------
style.WindowPadding: 8.00,8.00
style.WindowBorderSize: 1.00
style.FramePadding: 4.00,3.00
style.FrameRounding: 0.00
style.FrameBorderSize: 0.00
style.ItemSpacing: 8.00,4.00
style.ItemInnerSpacing: 4.00,4.00

Details:

By adding detailed tooltips for some tool windows I noticed some strange viewport behavior. As soon as a tooltip in a background window leaves the boundary if that window's viewport, the tooltip gets its own viewport and messes with the window order. A foreground window then gets pushed into the background while staying focused. To get it into the foreground again, it must first be unfocused, then focused again. I added exact instructions to the example code.

The focused window getting pushed into the background is the main issue. It staying focused is expected (if it were staying in the foreground that is).

A workaround in my application would be to display tooltips only for focused windows, but having the information just by hovering would be better.

Screenshots/Video:

viewport_tooltip

Minimal, Complete and Verifiable Example code:

	if ( ImGui::Begin( "Viewport A" ) )
	{
		ImGui::TextUnformatted( "- Move this window into its own viewport.\n"
		                        "- Move the window 'Viewport B' into its own viewport\n"
		                        "  overlapping this window.\n"
		                        "- Hover over this window so that the tooltip leaves\n"
		                        "  the window and opens its own viewport.\n"
		                        "\n"
		                        "'Viewport B' will be in the background after this and\n"
		                        "can't be clicked into the front without focusing this\n"
		                        "window first." );

		if ( ImGui::IsWindowHovered( ImGuiHoveredFlags_ForTooltip ) )
		{
			if ( ImGui::BeginTooltip() )
			{
				ImGui::TextUnformatted( "This tooltip just needs to be big enough\n"
				                        "so that it can easily leave the parent\n"
				                        "viewport. This will mess with the window\n"
				                        "order as described in 'Viewport A'." );
				ImGui::EndTooltip();
			}
		}
	}
	ImGui::End();

	if ( ImGui::Begin( "Viewport B" ) )
	{
		ImGui::TextUnformatted( "Follow the instructions in 'Viewport A'." );
	}
	ImGui::End();
@ocornut
Copy link
Owner

ocornut commented Feb 27, 2024

I investigated this and it appears caused by the fact that a child-parent relationship at the HWND level (honored by imgui_impl_win32) raise the parent along with the child.

in ImGui_ImplWin32_CreateWindow:

vd->HwndParent = ImGui_ImplWin32_GetHwndFromViewportID(viewport->ParentViewportId);
[...]
vd->Hwnd = ::CreateWindowEx(....., ....., ....., vd->HwndParent); // this will raise vd->HwndParent as well

At dear imgui level, this is triggered by code in WindowSyncOwnedViewport():

    else if ((window_flags & (ImGuiWindowFlags_Popup | ImGuiWindowFlags_Tooltip)) && parent_window_in_stack && (!parent_window_in_stack->IsFallbackWindow || parent_window_in_stack->WasActive))
        window->Viewport->ParentViewportId = parent_window_in_stack->Viewport->ID;
    else
        window->Viewport->ParentViewportId = g.IO.ConfigViewportsNoDefaultParent ? 0 : IMGUI_VIEWPORT_DEFAULT_ID;

If you remove ImGuiWindowFlags_Tooltip here it won't set the parent<>child relationship.

The commits are mostly 3ead982 (code moved in cce307a) and they were in reaction to #2409 which incidentally is to fix a similar bug with the other viewport.

I don't know what would be a good solution for now.

ocornut added a commit that referenced this issue Feb 27, 2024
@ocornut
Copy link
Owner

ocornut commented Feb 27, 2024

This was incorrect:
vd->Hwnd = ::CreateWindowEx(....., ....., ....., vd->HwndParent); // this will raise vd->HwndParent as well
It actually happens in ShowWindow(SW_SHOW);

Temporarily clearing GWLP_HWNDPARENT from the window at the time of showing fixes it: 4e8c43f

I confirmed that it didn't interfere with the fact that later clicking that child window (in the case of a non-tooltp) will raise the window.

I believe this is actually quite a good/desirable improvement. Thanks!

@ocornut ocornut closed this as completed Feb 27, 2024
@GamingMinds-DanielC
Copy link
Contributor Author

Thank you for the quick fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants