| |
| |
On 4/28/24 16:25 Gonzalo Garramuño wrote:
On 4/28/2024 11:16 AM, 'Albrecht
Schlosser' via fltk.coredev wrote:
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.
OK, thanks for confirmation. Can you try my patch (code above) ?
Note that I also change the type check to `p->as_window()` but that shouldn't affect the
behavior, it the "modern" way to determine whether a widget is a
window.
(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.
OK, let's recap and try to simplify the scenario, maybe to create a
small example program that triggers the issue so we are sure and can
test easier:
(1) You have a (main) window A (subclassed from an FLTK
window class)
(2) You open another window B (the small preview window)
(3) Window B is a modal (or non-modal) window (stays
on top of A)
(4) You drag some "object" (in the timeline) inside your
window A
(5) Your window A gets an FL_LEAVE event when the
mouse cursor leaves window A while dragging
(6) You hide window B while handling FL_LEAVE in window
A's handle method
Is all of this true? If not, please correct my wrong assumptions.
More questions: which of the windows (A, B, or both) are OpenGL
windows?
The
timeout was a work-around (which randomly failed too) to hide the
window.
According to your video with the crash you removed the timeout and
did it as described above. Is this correct?
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.
Now that you can reproduce the issue, can you also reproduce it on
Linux (X11 or Wayland) or macOS?
Note: I'm asking these questions because I wonder why this bug is
triggered in your code and was not reported earlier. Meanwhile I'm
pretty sure that the fix given above is correct and necessary but
I'm still wondering what the root cause of the issue may be.
Thanks for all your testing and for finding the issue.
--
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/1bdab201-1086-405f-a9fb-d4cbd6c6ff0c%40aljus.de.
[ Direct Link to Message ] | |
|
| |
