Comments on: Flash Player Bug: Removing an event listener in another listener for the same type fails

By: ian pretorius

ian pretorius — Thu, 19 Nov 2009 12:47:05 +0000

Hi David

“in OOP, both objects hear the event at the same time â€“”

I personally dont believe this statement is true, Actionscript is a single threaded stack based language , thus everything is sequenced according to the stack. Its simply as others have commented, a matter of the API (event.stopPropagation() , event.stopImmediatePropagation() ) been the entry points into event stack manipulation. I side with Josh in that its a matter of how flash is built and im sure it could be possible to engineer flash to update the copied list via interpreting some flag set by the removeEvent operation with each iteration of proccessing the listeners list.

By: David

David — Mon, 07 Sep 2009 21:26:05 +0000

Hey Josh,

The reason the event is still caught by dispatcherComplete2Handler is because this is Object Orientated Programming.

If you have mainly done procedural programming, you would expect the first handler to remove the second handler’s listener… in OOP, both objects hear the event at the same time – so by the time you have removed the listener, it is too late.

Hope this helps out.
Dave.

By: adampasz

adampasz — Sun, 05 Apr 2009 19:27:51 +0000

Never mind my second question. I see that the event is dispatched from the *copy* of the list, but removeEventListener operates on the original list.

By: adampasz

adampasz — Sun, 05 Apr 2009 19:24:04 +0000

“When an event is being dispatched, the event dispatcher makes a copy of the event listeners list. So this list canâ€™t be changed during the dispatch of an event.”
As a developer, how would I possibly know this (without reading your post). If the event list is locked during event dispatching, I would at least expect some kind of exception to be thrown to let me know that I’m doing something wrong by trying to modify the list. Also, if the list can’t be changed during dispatch, wouldn’t the output be:
1
2
1
2

By: Josh Tynjala

Josh Tynjala — Thu, 02 Apr 2009 14:39:01 +0000

Elliot, calling stopImmediatePropogation() on a GTween event won't help at all. That will stop one GTween instance from updating further listeners, but it will have no effect on other GTween instances. If A is paused during B's event, A will still receive the "tick" event from the internal timing mechanism and update one last time. Stopping propagation on a GTween instance's events does not stop propagation of events from this timer, and it definitely shouldn't because that could affect instances that have not been paused.

By: Elliot Chong

Elliot Chong — Thu, 02 Apr 2009 13:52:15 +0000

“pausing a GTween inside an event listener attached to another GTween causes the supposedly-paused GTween to update the target’s properties one last time”

If you place a stopImmediatePropagation() immediately after your pause statement for a tween, then priority should be more or less irrelevant in that instance. The final value will still be the the one set right when you paused it, as nothing will be updated after that.

I’m unsure of when GTween would need any different behavior, as developers are tasked with assigning the listeners for the tween’s updates, completes, etc. Could you give an example for when a developer using GTween wouldn’t be able to use this method effectively?

By: Josh Tynjala

Josh Tynjala — Wed, 01 Apr 2009 17:21:41 +0000

Thanks for the comments, folks. Personally, I’m still not convinced. For the record, I have no problem with event propagation and priorities. I use these features often. What’s interesting is that you all make this suggestion to use them, but Grant probably won’t be able to do that in GTween. He has an arbitrary number of event listeners where the only way to calculate a useful priority is after removing one of the listeners (and unless I’m wrong, you can’t change priorities at that point!). My GTween workaround above will probably be enough, but it certainly feels like more like a hack than a fix.

By: Elliot Chong

Elliot Chong — Wed, 01 Apr 2009 15:39:44 +0000

I also believe this is working as intended… I understand the confusion, but it’s not really a Flash Player bug.

I’d recommend setting the priority of the event listener you want to capture first higher than the others, and then use event.stopImmediatePropagation() in your listener to stop it from reaching subsequent listeners in the event chain.

By: Gabriel Mariani

Gabriel Mariani — Wed, 01 Apr 2009 11:56:30 +0000

But that’s the thing. You’re NOT removing it before the other event listener is being called. Like Joeri said, it’s a propagation stream, and in order to interrupt it (like what you are trying to do) is why they have stopPropagation() in the first place. They already solved for your problem, you just don’t like the solution.

By: Josh Tynjala

Josh Tynjala — Wed, 01 Apr 2009 09:06:12 +0000

Joeri, I considered that possibility, and I assume that’s probably how Flash Player is implemented. Even considering that, I still argue that it’s behaving incorrectly. If I remove an event listener before it is called, then I should not receive that event. I don’t care if I do it in another event listener or anywhere else. This implementation opens up a can of worms that only the most experienced developers will be able to easily understand. Honestly, who considers the possibility that an event might still be received after you’ve explicitly called removeEventListener()? Only the most superstitious coders, in my opinion.