DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2611 Version: 2.0-current Actually, your fix and the bug you're talking about doesn't explain the behaviour we're seeing. A modal window (or widget) eats all the incoming events, but *can also receive them*. What's happening here is that the window/widget is locking itself in an infinite loop, and thus is unable to receive anything (which is why it exhibits the behaviour you're describing). I probably misspoke - when I said "FLTK event loop" I didn't mean the capturing of X events, etc. It made sense in my head. :-P Now, of course, once the above behaviour is fixed the *next* item on the agenda would be your fix, as you're right - the InputBrowser would clearly not gain focus and modality. I really need to find some time to do a bit of heavy developing, but I'll be snowed under for the next couple of weeks. In the meantime, I'll commit your fix, because I suppose it does solve the issue, but doesn't triage the underlying problem. I think this problem was specific to X11, which means that there's (most likely) a simple fix somewhere in src/x11/run.cxx, but I'll have to follow this up. Thanks for the bug report and the fix. I hate triaging bugs that lock up X servers, personally!. Link: http://www.fltk.org/str.php?L2611 Version: 2.0-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
