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:
parent
131fec7866
commit
da0ee60864
2 changed files with 9 additions and 1 deletions
2
changelog_entries/moveto_message.md
Normal file
2
changelog_entries/moveto_message.md
Normal 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)
|
|
@ -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();
|
||||
|
|
Loading…
Add table
Reference in a new issue