| Summary: | SDL_ShowMessageBox and SDL_FlushEvents | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Daisuke <daisuke_asao> |
| Component: | events | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED INVALID | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | 2.0.2 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Attachments: | FlushEvent testcode | ||
SDL_FlushEvents() intentionally doesn't poll for more events so it can safely be called from event handler callback functions. A better fix for your use case would be just two lines: SDL_PumpEvents(); SDL_FlushEvents(SDL_FIRSTEVENT, SDL_LASTEVENT); I clarified the documentation to reflect this: This function only affects currently queued events. If you want to make sure that all pending OS events are flushed, you can call SDL_PumpEvents() on the main thread immediately before the flush call. |
Created attachment 1724 [details] FlushEvent testcode Bug: Events are not flushed when SDL_FlushEvents is called right after the return of SDL_ShowMessageBox. I require events to be ignored that are generated while a messagebox is shown. Attached file reproduces the problem: 1) start program, clicking inside screen produces printf 2) try closing the program 3) msgbox shows 4) click a few times inside the main window, no printf 5) click "no", msgbox dissapears 6) Queued printfs are shown, proving SDL_FlushEvents to be ignored when called right after return of SDL_ShowMessageBox I have also added a workaround (same file, enable this with the ifdef top of file) which requires me to call SDL_FlushEvents after calling SDL_PollEvents atleast once. But this is ugly. Let me know if this is a bug or expected behaviour.