| |
| |
NOTE: while I was almost ready to post this message a new reply from
Gonzalo appeared. I'm going to look into the other reply soon. My
questions are similar to what Manolo asked. I'm posting my reply
anyway as-is ...
On 4/28/24 10:50 Gonzalo Garramuño wrote:
On 4/28/2024 5:36 AM, Gonzalo Garramuño wrote:
Actually, the fix should be these two lines:
Fl_Widget* p = parent(); for (p &&
;p->visible();p = p->parent()) {}
if (!p || p->type() >= FL_WINDOW) break; //
don't do the unmap
Make that instead:
Fl_Widget* p = parent(); for (p &&
;p->visible();p = p->parent()) {}
if (p && p->type() >= FL_WINDOW) break;
// don't do the unmap
Gonzalo, I agree that the existing code is broken, and it was IMHO
broken since it was introduced in the year 2000 as Manolo mentioned.
However, a typo seems to be in your suggested code in in `for (p && ;p->visible();`
. I propose the following:
if (visible()) { Fl_Widget* p = parent(); for (; p && p->visible(); p = p->parent()) {} if (p && p->as_window()) break; // don't do the unmap } pWindowDriver->unmap();
(1) After seeing your last proposal I considered changing it to the
first proposal above, wondering which one was correct. Why did you
change the first proposal to the later one? I came to the same
conclusion, but can you elaborate why you changed it?
(2) Did you have a chance to test this code with the patch or let
your user test it? Did it change the behavior?
(3) I agree with Manolo that we should investigate and understand
why such old code triggers a bug (crash) in your code. Understanding
what happens is important to know *what* exactly needs to be
fixed. Maybe there's another bug elsewhere (in FLTK or
inyour application) that causes this unexpected behavior. As Manolo
wrote, it is possible that some code accesses a deleted widget or
window which causes undefined behavior. Do you have
any insights what may trigger the bug in your program?
The more info you can provide, the better we can fix the bug.
According to the stack trace posted elsewhere I assume that your
program hides either a window or another widget, maybe one that
contains a subwindow, inside a timer callback. Does this sound
plausible (possible)?
Maybe the crash is triggered because the timer callback is called
while the user has a menu open in your program. If we could confirm
this it might give us more clues. Can you please ask the user if the
crash happens while a menu is open?
If my assumption (timeout that hides a widget or window) is true,
then this could be a Windows specific issue triggered by a
particular Windows behavior that hides a modal (menu) window when
its "parent window" is hidden - where "parent window" is a Windows
specific relation and not FLTK's parent() relation of subwindows.
It would be great if you could provide us with some more information
about the program's state when the crash is triggered. Thanks in
advance.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/1673a68f-11cf-4d8c-8d82-c1af8bfb412e%40aljus.de.
[ Direct Link to Message ] | |
|
| |
