Drag and Drop Target Box does not remain within the Window #3272

Closed
opened 2020-05-29 15:10:57 +00:00 by Link1J · 4 comments
Link1J commented 2020-05-29 15:10:57 +00:00 (Migrated from github.com)

Version/Branch of Dear ImGui:

Version: 1.76 WIP
Branch: Master and Docking

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_glfw.cpp + imgui_impl_opengl3.cpp, imgui_impl_glfw.cpp + imgui_impl_vulkan.cpp, imgui_impl_win32.cpp + imgui_impl_directx11.cpp, Custom
Compiler: MSVC
Operating System: Windows 10

My Issue/Question:

The yellow boxes for drag and drop targets, do not stay within the window they are from. It does not appear to be affected by any chance to the renderer or backend.

Screenshots/Video

Yellow box breaks window bounds 2

Standalone, minimal, complete and verifiable example:
The Demo window works to show this.
Make the Demo window have a width of 93, then use the first drag and drop example with the color edits. That is what was done to get the screen shot.

**Version/Branch of Dear ImGui:** Version: 1.76 WIP Branch: Master and Docking **Back-end/Renderer/Compiler/OS** Back-ends: imgui_impl_glfw.cpp + imgui_impl_opengl3.cpp, imgui_impl_glfw.cpp + imgui_impl_vulkan.cpp, imgui_impl_win32.cpp + imgui_impl_directx11.cpp, Custom Compiler: MSVC Operating System: Windows 10 **My Issue/Question:** The yellow boxes for drag and drop targets, do not stay within the window they are from. It does not appear to be affected by any chance to the renderer or backend. **Screenshots/Video** ![Yellow box breaks window bounds 2](https://user-images.githubusercontent.com/22891267/83275194-d6446c80-a19c-11ea-9f22-faf79b0482ae.PNG) **Standalone, minimal, complete and verifiable example:** The Demo window works to show this. Make the Demo window have a width of 93, then use the first drag and drop example with the color edits. That is what was done to get the screen shot.
Link1J commented 2020-05-31 19:29:55 +00:00 (Migrated from github.com)

I'm pretty sure this is intended behavior.

Last I checked the window elements stay in window. The yellow box does not. Therefor unintended behavior. Note that the yellow box draws on the scrollbar, and the background.

> I'm pretty sure this is intended behavior. Last I checked the window elements stay in window. The **yellow box** does not. Therefor unintended behavior. Note that the **yellow box** draws on the scrollbar, and the background.
markitus18 commented 2020-05-31 20:04:01 +00:00 (Migrated from github.com)

Last I checked the window elements stay in window. The yellow box does not. Therefor unintended behavior. Note that the yellow box draws on the scrollbar, and the background.

Ah, yes, of course... I thought you were referring to the tooltip window. Too many hours of debugging today :) Removing my comment to avoid confusion.

> Last I checked the window elements stay in window. The **yellow box** does not. Therefor unintended behavior. Note that the **yellow box** draws on the scrollbar, and the background. Ah, yes, of course... I thought you were referring to the tooltip window. Too many hours of debugging today :) Removing my comment to avoid confusion.
rokups commented 2020-06-01 10:24:53 +00:00 (Migrated from github.com)

Turns out that this behavior is enabled on purpose. This is how it looks without explicitly allowing yellow rectangle to go out of bounds:
image
I have no idea what correct behavior is in this case. We have to wait for a verdict from @ocornut.

Turns out that this behavior is enabled on purpose. This is how it looks without explicitly allowing yellow rectangle to go out of bounds: ![image](https://user-images.githubusercontent.com/19151258/83400044-e5c8ed00-a40a-11ea-8130-1adb4f0150e3.png) I have no idea what correct behavior is in this case. We have to wait for a verdict from @ocornut.
ocornut commented 2021-06-30 14:14:41 +00:00 (Migrated from github.com)

Pushed a fix with 4ddb6b46c3
This intentional (see initial commit 4b94738c7e) but I frankly can't remember nor understand why I thought it was a good idea back then...
Same issue as #4281

Pushed a fix with 4ddb6b46c314045d75b565fc29170e7cb2327eca This intentional (see initial commit 4b94738c7e64a7a912a72b373063b42a407ec1bd) but I frankly can't remember nor understand why I thought it was a good idea back then... Same issue as #4281
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ocornut/imgui#3272
No description provided.