ActionScript 3.0 using closures for event handlers

Question

I tried doing this:

root.addEventListener(\"click\", 
   function () 
   { 
      navigateToURL(ClickURLRequest,\"_self\"); 
   });

And it

Answer 1

Just a side note on your code that I came across in the Flex In A Week set of tutorials on the Adobe web site. There, they said you should always use the constants for the event types rather than the string. That way you get typo protection. If you make a typo in the event type string (like say "clse"), your event handler will get registered but of course never invoked. Instead, use Event.CLOSE so the compiler will catch the typo.

Answer 2

I'm not sure if this will work but its worth a shot:

root.removeEventListener("click", arguments.callee );

More information about it can be found Flex lang ref

Answer 3

I found myself doing this a lot so I tried this. Seems to work fine.

addSelfDestructiveEventListener('roomRenderer', 'complete', trackAction, 'floorChanged');

private function addSelfDestructiveEventListener(listenee:*, event:String, functionToCall:Function, StringArgs:String):void
{
    this[listenee].addEventListener(event, function(event:Event):void
        {
            (event.target as EventDispatcher).removeEventListener(event.type, arguments.callee);
            functionToCall(StringArgs);
        })
}

Answer 4

It's not too much different than using a defined function, but maybe this will satisfy your needs. Remember that Functions are first-class objects in ActionScript and you can store and pass them around as variables.

protected function addListener()
{
    m_handler = function(in_event:Event) { removeEventListener(MouseEvent.CLICK, m_handler); m_handler=null}
    addEventListener(MouseEvent.CLICK, m_handler)
}
protected var m_handler:Function

Answer 5

I use this sometimes:

var closure:Function = null;
root.addEventListener("click", 
   closure = function () 
   { 
      navigateToURL(ClickURLRequest,"_self"); 
   });

root.removeEventListener("click", closure);

Answer 6

As has already been suggested, you may remove the closure from the chain of listeners from within the closure itself. This is done through the use of arguments.callee:

myDispatcher.addEventListener("click", function(event:Event):void
{
    IEventDispatcher(event.target).removeEventListener(event.type, arguments.callee);

    // Whatever else needs doing goes here
});

This will effectively turn the closure into a one-time listener of the event, simply detaching itself once the event has fired. While syntactically verbose, it's an incredibly useful technique for those many events that really only fire once (or that you only care about once) like "creationComplete" in Flex, for instance. I use this all the time when downloading data, since I think having the callback code inline makes it easier to understand. It is like hiding away the asynchronous-ness:

myLoader.addEventListener("complete", function(event:Event):void
{
    /* Even though the load is asynchronous, having the callback code inline
     * like this instead of scattered around makes it easier to understand,
     * in my opinion. */
});

However, if you want to listen to the event multiple times, this will not be very effective for obvious reasons. In that case, you need to store a reference to the closure somewhere. Methods are objects like anything else in ActionScript and can be passed around. Thus, we can alter our code to look like this:

var closure:Function;

myDispatcher.addEventListener("click", function(event:Event):void
{
    closure = arguments.callee;

    // Whatever else needs doing goes here
});

When you need to remove the event listener, use the 'closure' reference, like so:

myDispatcher.removeEventListener("click", closure);

Obviously, this is an abstract example but using closures like this can be pretty useful. They do have drawbacks though, such as being less efficient than named methods. Another drawback is the fact that you actually have to store away a reference to the closure if you ever need it. Care must then be taken to preserve the integrity of that reference, just like with any other variable.

Thus, while the different syntax may have its uses, it's not always the best solution. It's an apples and oranges kind of thing.