[docking] Window is movable even if the mouse is not directly on top of the window

[garyng]

I fat-fingered and hit submit issue without filling in the issue details, sorry for that!

In the docking branch, the window is moveable even if the mouse is not directly on top of the window:

[garyng]

I think this is probably because of the imgui window is still receiving mouse input events even if the window is not in focus:

[AyphixLLC]

@garyng Windows 10 maintains some sort of focus even if the window isn't in focus, that's why you can scroll up and down on windows that aren't in focus. I'm not sure if or how this effects ImGui.

[garyng]

@AyphixLLC I think that only applies to scrolling right? The original imgui doesn't have this problem though.

[garyng]

~~Is this because of the use of SDL_GetGlobalMouseState? The docs say~~

~~This can be useful if you need to track the mouse outside of a specific window~~

Probably not because of this.

@mellinoe Any idea?

---

EDIT:

~~Seems like removing https://github.com/mellinoe/ImGui.NET/blob/69ffb61fab4a9f06a00d86ca1fd7dcc74ffb192e/src/ImGui.NET.SampleProgram/ImGuiController.cs#L592-L594~~ ~~will fix the problem, since the mouse down flags are already set in https://github.com/mellinoe/ImGui.NET/blob/69ffb61fab4a9f06a00d86ca1fd7dcc74ffb192e/src/ImGui.NET.SampleProgram/ImGuiController.cs#L579-L581~~

~~Now the windows are not clickable when they are out of focus, but they still receive the "hovered" event.~~

It doesn't work...

[garyng]

ImGui.NET: the window still get "hovered" event even if the viewport (?) is not focused

Original imgui:

[BlizzCrafter]

It would be nice to know what's causing this and it would be nice to know a satisfying solution.

I noticed that the XNA sample project (which comes with this repo) still has this bug. But the Veldrid sample (also from this repo) works like it's meant to be.

This is not directly a bug with the docking branch, but rather a general one.

I just tested it with the current master branch.

@mellinoe

[BlizzCrafter]

Okay, I think that I found a solution to the problem and I created this gist here, which fixes the ImGuiRenderer.cs: https://gist.github.com/sqrMin1/7449ffb818f790678c979c6085540b94

I simply subscribed to the Activated & Deactivated events from the MonoGame Game class and setting an _inputPossible boolean field correspondingly.

In the UpdateInput prototype I check for the _inputPossible condition.

This happens right before ImGui.NewFrame() as the official ImGui FAQ recommends.

This FAQ also says: "Important: you should always pass your mouse/keyboard inputs to Dear ImGui[...]", which my solution kinda prevents in deactivated states. But this is exactly what I want in certain situations, despite that the FAQ also says: "This is because e.g. we need to detect that you clicked in the void to unfocus its own windows, and other reasons."

My tests doesn't give bad results so far.

However, if you work with WindowsForms (without a game class) and ImGui.NET, you need to implement the above mentioned steps in every form (subscribe to Activated and Deactivated events).

This is BTW also how the official MonoGame.Framework handles this:

1. Activated & Deactivated event subscription
2. Handle Input correspondingly

You just need to close the gap between the ImGuiRenderer and MonoGame or rather creating the bridge.

If there is a better solution I will be happy to hear it.

Cheers

[mellinoe]

@sqrMin1 The original issue here is about the multi-viewport Veldrid renderer. Are you seeing a similar problem in the MonoGame sample? I can't see any issue there, but I can repro the original one.

[BlizzCrafter]

I thought it could be a general problem, because I also got this bug in the MonoGame sample. Sorry for confusion.

I'm getting mouse-over effects on overlapping windows, but I couldn't directly click through with the current master.

However it was possible for me to reach "ImGui.IsItemHovered()" breakpoints:

This is why I initially came to the conclusion that this could be connected with this issue. But it could be also a bug for it's own, so I opened #238.

[Thraka]

The simple solution is to just check the game's active flag in the ImGuiRenderer.UpdateInput method:

protected virtual void UpdateInput()
{
    if (!_game.IsActive) return;