| | [ Return to Bugs & Features | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]
STR #1115
| Application: | FLTK Library |
|---|
| Status: | 5 - New |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | WIN32 |
|---|
| Summary: | Windows shown while popup menu was active disappear when the menu is dismissed. |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | Sadysta |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post Text ]
| |
| #1 | Sadysta
13:05 Dec 11, 2005 |
| This is resumption of STR #889. This time I've prepared a short demonstration code and some screenshots to make things 100% clear. | |
| |
| #2 | Sadysta
13:17 Dec 11, 2005 |
| Furthermore, once the second window disappers in the abnormal manner I can't show it anymore, even with a call to show() in a callback. See test2.cxx. | |
| |
| #3 | Sadysta
13:22 Dec 11, 2005 |
| And yet another weirdness. When I use iconize() instead of show() the second window doesn't even make it to the taskbar. Instead it acts like a MDI client window O_O See bug2.png. | |
| |
| #4 | Sadysta
13:28 Dec 11, 2005 |
| If you happen to experiment on the code I've provided please notice that you have to kill the application manually if the second window disappears as in this circumstances Fl::run() won't return even if you close the first window. | |
| |
| #5 | Sadysta
13:31 Dec 11, 2005 |
| I've seen this behaviour multiple times on Windows. I'm not sure right now if it's present on Linux because I use it less often than Windows. I'll check it out ASAP. | |
| |
| #6 | alvin
14:51 Dec 11, 2005 |
| I have tried test.cxx on SUSE 9.3. I notice the following:
test.cxx:
A window appears with a menu button. When clicked a submenu is shown with entries: One, Two, Three. When I click on One, another window is shown. I close the new window by clicking on the top-right X. When I click on the One menu item a second time, the new window does not reappear.
test2.cxx:
A window appears same as with test.cxx. Just as in test.cxx, when I click the One menu item a new window appears. However, when I close the window by pressing the top-right X, the window disappears and then immediately reappears. This happens only for the first time I click on the One menu item. All other subsequence attempts behave as expected. The window appears when One is clicked. Then disappears when the top-right X is clicked. The window will not reappear until the One menu item is clicked.
Hope this helps,
Alvin
SUSE 9.3 Pro
Kernel 2.6.11.4-21.9
Xorg 6.8.2 | |
| |
| #7 | Sadysta
21:57 Dec 11, 2005 |
| As the matter of fact you were not supposed to click on "One" (especially in test.cxx). You should've opened the popup menu and waited 3 seconds until the second window was shown via timeout trigger and then dismissed the popup menu only to find out that the second window would also disappear.
Thanks for testing, anyway :) | |
| |
| #8 | alvin
07:54 Dec 12, 2005 |
| My bad. This time I ran test.cxx (compiled using 1.1.x r4690).
I started 'test' and within 3 seconds a 2nd window with the title "Test 2" appeared. I closed the first window (the one with the Menu button). However, "Test 2" remained. The program terminated when I closed "Test 2".
With test2.cxx, the "Test 2" window appears within 3 seconds. The only difference with test.cxx is that if I select Menu->One in the first window, the "Test 2" entry on my taskbar flashes. This does not happen with test.cxx. | |
| |
| #9 | Sadysta
10:04 Dec 12, 2005 |
| Ehh... I'm afraid you don't understand. You should not only start the application, but also open the popup menu (i.e. click on menu button exactly once) and then wait for the second window to appear. After it's shown you can dismiss the popup menu or even close the first window. Anyway, the second window will disappear along, despite it shouldn't. | |
| |
| #10 | Sadysta
10:14 Dec 12, 2005 |
| I've just checked the issue on Linux myself and it's not present. So it's possible that you might've done everything perfectly fine and you didn't notice the fault because it simply wasn't there. I'm sorry if this is the case. I just had an impression that you weren't quite following my instructions. | |
| |
| #11 | Sadysta
10:15 Dec 12, 2005 |
| Still, the problem IS PRESENT ON WINDOWS! It's 100% repeatable and really serious! | |
| |
| #12 | matt
16:15 Dec 12, 2005 |
| OK, I found the problem. Posting new windows while a popup menu is up makes FLTK beleive, that the new window is a submenu of the posted menu. This is so because the original author assumed that no callbacks are called during a menu popup phase. Until recently, all other events were actually blocked while a popup was handled, but users did not like that.
Well, to make it short, I have no spontaneous fix. Maybe someone else has time to look at this. The offending code is line 1299 in Fl_win32.cxx:
} else if (Fl::grab()) parent = fl_xid(Fl::grab());
^^^^^^^^^^^^^^^ do we really need this?
But to not let you hang in the rain. Putting you "show()" code between these lines will at least help as a quick fix:
Fl_Window *wg = Fl::grab();
Fl::release();
w -> show();
Fl::grab(wg); | |
| |
| #13 | mike
17:05 Dec 13, 2005 |
| I think we really do need the current code, and the workaround you posted is the only possible fix for FLTK 1.1.x. | |
| |
| #14 | matt
12:31 Apr 22, 2008 |
| Must be verified for 1.3 | |
| |
| #15 | AlbrechtS
12:04 Jan 31, 2022 |
| FTR: A quick test using FLTK 1.4 current (Git) shows:
Linux: not affected
Windows: affected. Tested on Linux running the cross-compiled demo program under wine.
macOS: not tested. | |
| |
| #16 | AlbrechtS
12:06 Jan 31, 2022 |
| Changed "Fix Version" from "Will Not Fix" back to "Choose Version". | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
