@fire-eggs Thanks for testing and for the source code - however ...

Meanwhile I found another - very likely more appropriate - fix. The real (?) cause of the issue was AFAICT a regression introduced when switching to the FLTK 1.4 driver model. You can verify that this is a regression by building the respective demo programs with FLTK 1.3. Does it work for you in 1.3?

You and others are invited to test the following tiny patch which fixes the regression. I'm about to commit it but for now only in my private fork (for testing on Windows).

index 220e4603d..2d2eb2021 100644
--- a/src/Fl_Tooltip.cxx
+++ b/src/Fl_Tooltip.cxx
@@ -301,6 +301,7 @@ void Fl_Tooltip::enter_area(Fl_Widget* wid, int x,int y,int w,int h, const char*
       Fl::remove_timeout(tooltip_hide_timeout);
     }
     Fl::add_timeout(Fl_Tooltip::hoverdelay(), tooltip_timeout);
+  } else if (Fl_Tooltip::delay() < .1) {
     // possible fix for the Windows titlebar, it seems to want the
     // window to be destroyed, moving it messes up the parenting:
     if (Fl::system_driver()->use_recent_tooltip_fix() && window && window->visible()) {

I'll let you know about my Windows tests ASAP. I'd appreciate to see your test results with my new patch (above, in this comment). TIA.

PS: I'll look at your code later...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.