That commit talks about a special case when the mouse leaves the plugin window. Not sure if it would fix it as well? I don’t really want to use the latest develop, as I prefer my frameworks a bit more mature. As long as it’s on the radar and gets fixed within the next few days, I’m happy.
This is the function that will send a mouse-enter:
And as you can see, that code should make it impossible to send a mouseEnter without giving the previously-over component a mouseExit (unless the previous one got deleted). So I think we’d want to see some sample code that reproduces your problem before investigating, as I suspect it might be something else that you’re misinterpreting rather than it dropping an event callback.
Well, it depends exactly what you mean by that. Its purpose is just to handle components with unusual shapes - if you make it always return a consistent value for a given coordinate then nothing should go wrong.
But if you were to do something silly like make its return value depend on other external factors like the state of the mouse, or focus, or other components, then all bets are off.
They turn themselves on and off, depending on how much content is in the viewport. It’s a standard ListBox. Outside my control. I wish the viewport had a “setScrollbarAlwaysOn (bool horizontal, bool vertical)”, so they simply stayed on and the width of the actual ListBox content wouldn’t fluctuate, but that’s outside my control.
I can post the hitTest code here later (I’m on mobile right now), but shouldn’t mouseExit get called no matter what, as soon as hitTest for the component returns false and it returned true before?
Did you try my suggestion of removing your hitTest code and seeing what effect that has? It would seem sensible to find out whether the hit test is actually involved before spending more time discussing how it works.
Well yes, you can see in the code above how that’s enforced. Like I said earlier, the only way it would lose an event would be if the old component was deleted. And if you have an external listener that’s listening to all mouse events in a hierarchy, then you could expect it to see a mouse enter without an exit if a component was deleted while the mouse was over it. Maybe that happens for one of the subcomponents in your listbox.
Yes, I’ve removed the hitTest code and it works as it should. But now I get hover mouseHovers when the mouse is over the scrollbar:
Here is my hitTest code:
bool GUI_Listbox::hitTest (int x, int y)
if (getViewport ()->getVerticalScrollBar ()->isVisible ())
const int scrW = getViewport ()->getScrollBarThickness ();
const int margin = scrW + getOutlineThickness () * 2;
if (x >= (getWidth () - margin) && x < (getWidth () - (margin - scrW)))
return ListBox::hitTest (x, y);
As you can see, there is nothing nefarious going on.
No, no components are deleted or being added or anything like that. It’s simply two ListBoxes side by side, both with lots of entries in them (hence the scrollbar turning on) and when I move the mouse quickly between the left and right control (from the left to the right), there is a very good chance (>10%) that “mouseExit” doesn’t get called for the left control.
If I only leave the “return ListBox:hitTest (x, y);” in there and comment the rest out, I can’t reproduce the problem at all.
Well, the scrollbar’s visibility will get changed by some callback that depends on which component the mouse is over and you’re using that in deciding whether the mouse is over this one… so presumably there’s a subtle interaction there that’s going wrong for you. But I really don’t think this counts as a library bug.
Why do you make these weird and specific assumptions? No, the scrollbar is not randomly there and then not.
Again: these are two listboxes, side by side. Both have items in them that exceed the viewport. Both show their scrollbar. Nothing is changing except me moving the mouse. No magic is happening in the background hiding the scrollbar or changing the lists.
I will, in the next few days, create a standalone demo, then you can see it for yourself.
Alternatively we can do a remote-desktop session via Skype and I can show you the problem (and associated source) in action. Heck, I would even pay money for you to do it.