DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L1971 Version: 1.1.9 I have a pop up Fl_Menu_Button that covers my main widget, so that I can get context menu pop ups on a right-click. All fine so far. But... my underlying "main" widget needs to get FL_ENTER and FL_LEAVE events, and as the cursor moves about, it gets cascades of these. Which rather spoils what I'm trying to do! With the pop up Fl_Menu_Button disabled, the main widget only gets FL_ENTER and FL_LEAVE the one time each, as you'd expect. The docs say: "A popup menu button is invisible and does not interfere with any events other than the mouse button specified" I'm fairly sure this code used to work (it's old stuff I was working on a long time back) so I'm not sure what gives now. I see the erroneous behaviour on OSX, Linux, and WinXP. Lookng at the src for Fl_Menu_Button suggests it should work; indeed the first test in the handle method there switch (e) { case FL_ENTER: case FL_LEAVE: return (box() && !type()) ? 1 : 0; Should be returning 0 in my case, so should be OK. Nikita Egorov suggested the bug was related to the behaviour of belowmouse, and a quick glance at that code suggests it might indeed be suspect: void Fl::belowmouse(Fl_Widget *o) { if (grab()) return; // don't do anything while grab is on Fl_Widget *p = belowmouse_; if (o != p) { belowmouse_ = o; int old_event = e_number; e_number = dnd_flag ? FL_DND_LEAVE : FL_LEAVE; for (; p && !p->contains(o); p = p->parent()) { p->handle(e_number); } e_number = old_event; } } It looks at first glance as if this might generate FL_LEAVE events for a pop-up menu button as we move, perhaps inducing this observed failure. I guess that this was introduced to provide DnD support at some point? Perhaps it used to work before that? -- Ian Link: http://www.fltk.org/str.php?L1971 Version: 1.1.9 _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
