|
|
On 4/28/2024 11:16 AM, 'Albrecht
Schlosser' via fltk.coredev wrote:
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();
Agreed. The typo is because I did not copy the code, I wrote it
manually. Sorry.
I have these questions:
(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?
Because I think the window where the FL_HIDE is should still get
unmapped, as it is being shown. Calling break; would not unmap 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?
I sent it to my tester (have not heard back). But since, I was able
to reproduce it. See my videos.
(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 problem seems to be that the Window is hidden while being in an
FL_LEAVE event of another window.
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)?
The timeout was a work-around (which randomly failed too) to hide
the window.
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?
No. It is not a menu opened, it is calling hide() on another window
from a handle() of another.
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.
I think indeed it was a Windows issue (bug). Sadly when I wrote the
timeout code, I did not document *why* I wrote it and had not delved
into FLTK's code.
--
Gonzalo Garramuño
ggarra13@gmail.com
--
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/2a7e5e79-4886-48fa-95b3-712a53cb7267%40gmail.com.
[ Direct Link to Message ] | |
|
| |