Spurious MOUSE_OVER Event

First, to put this in context I am trying to set a variety of different mouse cursors depending on where and what the mouse pointer is doing.

This one really has me baffled.

I have a some nested Sprites (so they are all EvenDispatcher subclass instances) and when I MOUSE _DOWN on one of the objects at the top of the display list it (spuriously) fires a MOUSE _OVER event on one of its ancestors (lower in the display list).

And here is the really weird part: The MOUSE _OVER listener on the ancestor detects the event in the “AT_TARGET” event phase which -is- should be impossible! (My first thought was that I could neutralize this problem by selectively executing the ancestor’s MOUSE _OVER listener function only if the event was detected in the Bubbling phase, but since it is in the AT_TARGET phase (same as when it gets a genuine MOUSE _OVER event) I can’t use that workaround.

At no time,when this problem happens, is the mouse pointer actually ‘over’ the ancestor on which that MOUSE _OVER listener exists. In fact to observe this error I have to MOUSE _DOWN on the child without moving the mouse at all, otherwise the “wrong” cursor just flickers momentarily (and then corrects itself) because the function that sets the correct cursor on the child object is itself triggered by a MOUSE _OVER listener on the child. (though this is also a bit of a mystery because the mouse never moves out of the child and the “MOUSE_OVER” event on the child should only fire if it moves back into it from outside! It’s behaving almost as though the ‘mouse down’ on the child is opening a ‘hole’ in it, through which its ancestor detects the sudden appearance of the mouse pointer and interprets it as a MOUSE _OVER event, and when the mouse moves again if fires the MOUSE _OVER” event on the child (on which it was already ‘OVER’)!

Anyone else ever encountered this problem? .. Found a solution?

if(event.eventPhase != EventPhase.AT_TARGET)

Would that do the trick?

CrackerJack said

if(event.eventPhase != EventPhase.AT_TARGET)

Would that do the trick?

No, I mention above that was how I first tried to work around it, but the ancestor is detecting the MOUSE _OVER event in the AT_TARGET phase, even from a (non-moving) click on the child.

Does the child have state change when MOUSE _DOWN and it’s mouseChildren property is true ? In that case if that state change add new InteractiveObject into the MOUSE _DOWN target’s child, all their ancestor’s will fire MOUSE _OVER event again.

MouseEvent.relateObject may help find out the interactive order.

( the replacing mouse cursors, need to be mouseEnabled/mosueChildren false, but this probably not need to be mentioned )

Solved! .. but it was a long journey getting there …

savorks said
Does the child have state change when MOUSE _DOWN and it’s mouseChildren property is true ? In that case if that state change add new InteractiveObject into the MOUSE _DOWN target’s child, all their ancestor’s will fire MOUSE _OVER event again.

I’m not sure what you mean by “state change”. Anyway. I realized I did not need to have the object with MOUSE _DOWN listener as a child of the object with the MOUSE _OVER listener, it just had to be above it in the display list) so I rearranged the object hierarchy. (From here on I will refer to the objects as “top” and “bottom” instead of “child” and “ancestor”) The surprise then was that it made no difference! The bottom object still received a MOUSE _OVER event when the top object was the target of a MOUSE _DOWN event trigger on it.

MouseEvent.relateObject may help find out the interactive order.

I had already tested that and the top object was, as expected, the “relatedObject” on the spurious MOUSE _OVER event. But for two reasons I didn’t want to use that to “fix” the problem: 1) the current architecture does not allow for making the class that contains the bottom object object aware of the instance name of the top object (which is in another class) and it would be against my software engineering sensibilities to bind the classes so tightly and 2) The graphical layout puts the top object right on one edge of its containing object, so moving the mouse off that edge onto the bottom object would fire a valid MOUSE _OVER event on the bottom object with the top object as a valid relatedObject. So filtering out MOUSE _OVER events on the bottom object when the relatedObject is the top object would occasionally cause the cursor selection to fail when the mouse moved off the top object directly onto the bottom object.

The top object is the “tab” on a slider (like a scrollbar for another purpose) and the slider sits right on the left edge (x=0) in a rectangular window. That window in turn sits over (but is now not a child of) the bottom object ( a background ).

I wondered if the fact that the leftmost pixel of the slider (and its tab) was directly adjacent to the background had any bearing on this problem so I tried moving the tab one pixel to the right, within the slider. No luck. But then I tried moving the whole slider one pixel to the right within the window, and it removed the problem! Unfortunately, the layout design doesn’t allow this (they are potentially tiny windows with hairline borders on the graphics and the one pixel offset on the slider looked ugly.

Finally I wondered if the fact that the MOUSE _DOWN on the tab started a “drag” on itself had anything to do with it. I commented out the “startDrag” and lo-and-behold the spurious MOUSE _OVER event disappeared. Further experimentation revealed that it was not the “startDrag” itself, but the value of the “lockCenter” parameter (which I was setting to “true”) that caused it. So I just manually set the tab’s y value to the mouse pointer y before calling startDrag() with lockCenter:false (same effect as “lockCenter:true, as it only moves vertically)

The sad thing is I usually don’t use startDrag(), preferring to implement constrained dragging manually on MOUSE _MOVE and using ‘updateAfterEvent’, but I decided to throw in a startDrag for speed, planning to maybe change it out later

So problem solved. I now no longer get a flash of “arrow” cursor when mousing down on the slider tab … but Adobe owes me a day

Glad you solved it now

theflyingtinman said
I’m not sure what you mean by “state change”.

What I mean was something like this Example

Bottom clip contains Top clip and its text flash when MOUSE _OVER trigger on Bottom clip, and the Top clip have two different states (change by MOUSE _DOWN on Top clip), and you can see Bottom fire MOUSE _OVER event when MOUSE _DOWN on Top clip.