Question

I have run into a problem attempting to redispatch mouse events in ActionScript 3, which I am admittedly a bit incredulous about. I have narrowed it down to the MouseEvent.clone() method appearing, well, completely broken. The following event handler:

    private function handleMouseMove( evt : MouseEvent ) : void
    {
        trace("mousemove", evt.stageX, evt.stageY);
        var newEvt : MouseEvent = evt.clone() as MouseEvent;
        trace("mousemoveclone", newEvt.stageX, newEvt.stageY);
    } 

Results in the following output, ad infinitum:

mousemove 167 206 
mousemoveclone 0 0

This matches what the code I was redispatching the MouseEvent to was receiving, hence my hypothesis of the broken clone function.

This is directly contradictory to what the linked documentation indicates should happen, unless I have missed something. I am at an entire loss as to what I did (or did not do) that could possibly cause this behavior. Did the AS3 guys really forget to read their own documents on Event.clone()?

I can work around this by instead using function objects for my specific use case, but I'd prefer not to. Any ideas?

Edit: The localX and localY members are being properly cloned it seems, which puts me at even more of a loss as to what is going on here.

Was it helpful?

Solution

Thats a known bug. You can see the bug report here: http://bugs.adobe.com/jira/browse/FP-343

Everything else should get cloned though. You can always just assign stageX and stageY manually until the bug is fixed.

OTHER TIPS

I realise this thread is 7 months dormant, but just to update this a bit - this is still active in FP10 and Flex4. It also happens if you redispatch the event. i.e.:

private function mouseListener( e:MouseEvent ):void
{
    dispatchEvent( e );
}

that dispatchEvent() call seems to be the equivalent of a clone(), so the stageX and stageY are set to 0

This is a pretty old question, but it was what came up when I Googled for a solution, and what's here is just not comprehensive enough.

The reason this hasn't been "fixed" is because it's working as intended. The stageX and stageY values are calculated when you invoke the getter, using the event's target to do the localToGlobal conversion. This is necessary so that the numbers remain correct even if the target object has changed position, scale or rotation since the event was dispatched.

Your two options if you really need to redispatch a MouseEvent with correct stageX and stageY values are:

  1. Create a custom subclass of MouseEvent that overrides the stageX and stageY getters. You can either store the original target and do the localToGlobal calculation yourself or you can store static values for stageX and stageY using the values that are there when you clone the original event.

  2. Extend Sprite and add your dispatcher to the stage so that the stock MouseEvent will work properly.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top