> It's a combination of more than one fact - I tested it for a while, > and the attached patch (for FLTK 1.3) fixes _almost_ all symptoms. > However, this is only for testing, I could not do any regression > tests - maybe there are side effects... > > (E.g. the modification in Fl_Group.cxx filters FL_LEAVE events, but > I don't know if this would be needed for other reasons). > > The fact that dragging the mouse sent events to the wrong window > (and therefore generated FL_LEAVE events) had to do with the > SetCapture() call that always used the main window for mouse events > after clicking (and holding) a button. I changed it to use the > "mouse_window", but maybe this also has side effects. > > The last remaining issue is when you enter the GL window with the > mouse. Windows _first_ sends a WM_MOUSEMOVE message with the hWnd > of the (entered) GL window, and then a WM_MOUSELEAVE event with the > (just left) main window's hWnd. This leads to an FL_ENTER event, > immediately followed by an FL_LEAVE event and another FL_ENTER > event for the GL window. But there are the same number of FL_ENTER > and FL_LEAVE events with this patch. > > More to come ...
The thing I still don't understand is whether we really need the TrackMouseEvent() mechanism or not, given that it seems problematic here... I don't really get what it does (since builds without it seem to function) and if it generates floods of enter/leave events on a mouse move... well that just seems like a Bad Thing... Do we need it? How does it help us? -- Ian _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
