Using a different library to open a message box after creating a winit event loop results in a hang.
fn main() {
let _event_loop = winit::event_loop::EventLoop::new();
tinyfiledialogs::message_box_ok("", "", tinyfiledialogs::MessageBoxIcon::Info);
panic!("Doesn't reach here");
}
I've tested this with both tinyfiledialogs and nfd on Windows 10. Other dialogues like open/save file work fine (except when an existing file is chosen, since it brings up a confirmation message box).
This is on winit master d103dc2. It seems like 0.22.2 is okay with the message box, but panics afterward due to #1611.
Does your program hang indefinitely if you do the following instead?
fn main() {
let event_loop = winit::event_loop::EventLoop::new();
event_loop.run(|_, _, control_flow| {
tinyfiledialogs::message_box_ok("", "", tinyfiledialogs::MessageBoxIcon::Info);
*control_flow = ControlFlow::Exit;
})
}
Yep. It also hangs regardless of whether or not a winit window is open and handling events at the same time.
I'd assume the dialog itself actually works? So you can interact with it and click it?
The message box actually doesn't display at all on master (sorry, should have mentioned that). In addition, it seems to even lock up the program that it was run from (VSCode, cmd, etc).
On 0.22.2 the message box displays and you can interact with it, but winit panics after it closes.
I did some bisecting, and dd866a7 (#1615) introduces the hang and makes the message box not show itself, which is consistent with what you've reported, @branpk.
It seems like things were working correctly up until the Windows event loop refactor in #1496 (b4c6cdf) got merged, at which point message boxes began making winit panic with thread 'main' panicked at 'either event handler is re-entrant (likely), or no event handler is registered (very unlikely)', D:\winit\src\platform_impl\windows\event_loop\runner.rs:236:18.
The lock-up of parent applications that happens when you experience the hang is likely due to how tinyfiledialogs uses MessageBoxW(GetForegroundWindow(), ...) instead of MessageBoxW(ptr::null_mut(), ...). native-dialog uses the second form, and does not trigger the lock-up.
I tried attaching a debugger after the bug was triggered and it seems like it always gets stuck inside GetMessageW here when using native-dialog and tinyfiledialogs. The dialog library always gets stuck inside MessageBoxW.
A temporary fix would be to spawn your message boxes on a background thread.
I had similar problem with msgbox crate and solved it with a workaround from StackOverflow site: https://github.com/bekker/msgbox-rs/pull/16
Pressing Alt seems to make the message box appear. This requires that you either don't change the focus after creating the message box or have a Winit window in focus.
Removing the WS_VISIBLE style from the "event target window" seems to make message boxes behave correctly, but that probably breaks something elsewhere.
This issue didn't get linked from #1769, which seems to fix the issue for me.
That PR just got merged, so could you try using the latest changes on the master branch, @qthree & @branpk?
Ha I got good scare when I saw this in my PR:

I thought I broke message boxes for some one else somehow馃槄
The bug seems resolved on master and 0.24.0. Thanks all!
Most helpful comment
The bug seems resolved on master and 0.24.0. Thanks all!