Fix race condition causing moveto messages to immediately close

If a mouse click causes a delay and then a message to appear, for example
when moving a unit triggers an `[event]name=moveto`, then the message
would sometimes flash on screen and then disappear with barely enough time
to see which character's portrait was used, let alone to read it.

Although there's already logic to not be triggered by the same mouseclick that
caused the unit to move, it had a race condition if the MOUSE_UP happened
around the time the the dialog's pre_show() function was running.

(cherry picked from commit 26ead85914)
This commit is contained in:
Steve Cotton 2024-03-28 15:56:28 +01:00 committed by Steve Cotton
parent 131fec7866
commit da0ee60864
2 changed files with 9 additions and 1 deletions

View file

@ -0,0 +1,2 @@
### Miscellaneous and Bug Fixes
* Fix: releasing a mouse button at the same time as a dialog pops up sometimes dismissed the dialog immediately (issue #8644)

View file

@ -555,8 +555,14 @@ int window::show(const unsigned auto_close_timeout)
try
{
// Start our loop drawing will happen here as well.
// According to the comment in the next loop, we need to pump() once
// before we know which mouse buttons are down. Assume they're all
// down, otherwise there's a race condition when the MOUSE_UP gets
// processed in the first pump(), which immediately closes the window.
bool mouse_button_state_initialized = false;
mouse_button_state_ = std::numeric_limits<uint32_t>::max();
// Start our loop, drawing will happen here as well.
for(status_ = status::SHOWING; status_ != status::CLOSED;) {
// Process and handle all pending events.
events::pump();