Fixed same-frame click/release bug

[BlaiseRideout]

Fixes Issue #1992 but also fixes the same issue in a general way for all platform impls.

Currently only tested for Win32.

There may be a better approach that involves a larger change to the way ImGui and its components handle mouse button input, but I'll leave that to those who are more familiar with the codebase as a whole and the consequences of such a change.

[ocornut]

Thank you Blaise, I realize I never got around to reply to this specific PR and apologize for that.
The reason I didn't reply was that I am hoping to incorporate an IO queue handled by core imgui which would create a centralized solution for this issue. I hope we can take care of that soon but for now this PR is a good reference and it's tempting to merge some of it sooner. Will get back to it later, thanks for your patience.

[LB767]

This will not get called in case of a mouseup happening before NewFrame() since this is where io.MouseDown gets updated.
As a result clicking on an imgui window does not release mouse capture and trying to click on the main window bar at the top to move, minimise or close it does not work.
An easy fix is to make ::ReleaseCapture not based on io.MouseDown but on the actual hardware inputs WM_LBUTTONUP etc...

[ocornut]

Better late than never, apologies @BlaiseRitchie for not reacting sooner. Your PR was the closest intermediary solution but we wanted to overhaul and fix this more generally, this is now done.

Dear imgui 1.87 WIP now uses a new IO api (e.g. io.AddKeyEvent() io.AddMouseButtonEvent() etc.) which implement an input trickling queue, normally solving this problem correctly and everywhere for all types of inputs. We'll monitor feedback and expect bugs to have creeped as we reoverhauled that system.

See e.g.

• new IO api b8e56dc
• input queue 7374b96
  There are many other commits but those should provide a good general sense of what changed.

Also see #4858 for a general overview (we'll improve this topic soon).