FL_LEAVE sends bad coordinates on Windows

[CendioOssman]

We rely on the FL_LEAVE event to tell us in which direction the mouse cursor decided to leave. This works fine on X11 and macOS, but not on Windows. We get an FL_LEAVE, but the coordinates are not correct.

The issue seems to be that the event FLTK gets on Windows doesn't include any coordinates, so FLTK simply uses the last coordinates it knows about. A call to GetCursorPos() is probably appropriate when getting this event.

[Albrecht-S]

Off the top of my head: I believe that FLTK sends FL_LEAVE events to widgets as a result of mouse move events (which ought to include coordinates, obviously). Therefore I assume that this issue is related to leaving the window, for instance on window focus change, maybe because another window gets raised by any other event. Can this be true?

If this is true, then the cursor might still be inside the bounds of the window when the FL_LEAVE event gets sent. This is maybe the case you're seeing.

However, this is only a guess because I don't have any real data. Can you describe what happens when you receive such FL_LEAVE events with "bad coordinates", i.e. what kind of message Windows sends to the FLTK window that causes this? Or at least what user action is causing these events?

[Albrecht-S]

A little research shows that we can also send FL_LEAVE events (under Windows) when we receive a WM_MOUSELEAVE message from Windows. This message does not contain mouse coordinates. According to the docs this message is "Posted to a window when the cursor leaves the client area of the window specified in a prior call to TrackMouseEvent". (According to code comments this is only true for the main application window.)

Using TrackMouseEvent is the default, but "you can disable it by defining NO_TRACK_MOUSE" (see src/Fl_win32.cxx) when you compile FLTK. IMHO it would be worth a try to do this for testing, to see if this changes anything and if yes, what exactly. I'm not suggesting that this be a solution, only a test.

OTOH you could try to add the suggested GetCursorPos() call to the handling of WM_MOUSELEAVE in src/Fl_win32.cxx yourself and report if this fixes the issue for your cases. Can you do this?

[CendioOssman]

I'm afraid we're a bit swamped here at the moment, so at least not right now. :/

[Albrecht-S]

See also issue #210 regarding FL_MOUSEWHEEL events.

[Albrecht-S]

@CendioOssman Is this issue essential for TigerVNC?

[CendioOssman]

It can be annoying in some cases but it's not a critical issue, no. It makes it difficult to hit edges, e.g. with GNOME's hot corner.