Using the Delegate class to manage scope
October 25th, 2007 . by polyGeek| Download code samples |
The Delegate class is used to specify the scope that a method/function operates in. It’s primary use is for Flash components and managing the events they dispatch. I personally don’t use the Flash components so I never came across it. If you’ve never heard of it either then get ready for a really cool addition to your coding toolbox.
Suppose you are creating a setInterval. You would do something like this:
That’s pretty much the way I always create intervals. When you run it you’ll get undefined for this.
The other way to create an interval is like this:
That solves the problem of scope in the function call. But there’s yet another way:
The Delegate class is like a Jedi mind trick for methods/functions. It says, “this is not the scope you are running in. Use this one instead.”
The only downside I can find with using Delegate is that you can’t pass arguments to the method/function that you call. At least I can’t find any documentation on that.
Note: a reader commented below that there is a way of using the Delegate class, or something like it, that does allow for passing parameters. Here is the link: person13.com/articles/proxy/Proxy.htm
Using the Delegate in this example is a little more code to write for the same result as the second approach but this isn’t really what Delegate was meant for.
setIntervals could get a little messy when you’re using them inside classes. You pretty much had to create nested functions so that you would be able to clear the interval later. Or the setInterval number could be a property of the class but that comes with it’s own baggage.
In my book this is where Delegate really shines.
That is a nice clean way to create methods that can be run on an interval and cleared when wanted.
Making Mouse listeners
When you create a Mouse Listener the scope of the function callback is the object that is listening to the Mouse events. And that’s usually not the scope you want to run in because it’s sort of like an island in the middle of a huge ocean.
The standard Mouse listener looks like this:
You’re sort of left hanging on the scope of the MouseListener1 object there. Not a whole lot of good. Using Delegate we can make that function run in any scope we want to. For this simple example it will run in the scope of the _root.
Another solution is to attach the scope that you want to the listener object like this:
That’s pretty much the way I did things before learning about Delegate. This approach works fine for most occasions. In my estimation the best reason for using Delegate is that it’s just more elegant. Using this.thisRef seems like a bit of a hack to me. Although I’ve used it countless times.
Creating Interface elements
Here’s an example of how you might use Delegate in a class where you are creating user interface elements, otherwise known as buttons. :-)
In this class I create a simple button. I pass along a MovieClip to create the visual elements inside of, the button label, the width and height of the button, and weather to use Delegate to manage the onRelease event or attach a reference to the button instance via thisRef.
The basic problem when creating interactive elements in a class is that when the user clicks on one of them the scope is automatically the MovieClip they just clicked on. Not the class that created the button in the first place. That’s where the data, or access to the data, would be handled.
There are numerous ways to handle this problem. You could create static methods in a class and pass along information. And you can dynamically attach properties to the MovieClip when it’s created. In that way it can identify itself. But it can’t get access to the instance of the class that created it without attaching this inside the class, as I did with the Mouse listener above.
By using Delegate you can make the button operate in the scope of the the class instance which created it. That can be very handy. The downside is that now you’ve lost reference to the actual MovieClip that was clicked on. That can be solved very simply by keeping a reference to the MovieClip as a class property.
Here is an example:
You can see that with this class you can either use Delegate or attach this to the Button instance. Here’s an example of two instantiations that use the two approaches.
No need for Delegate in Actionscript 3
The good news is that in Actionscript 3 events are handled completely differently, or should I say correctly. In Actionscript 1/2 events were sort of added willy-nilly to the language/player over time. With Actionscript 3 we can create classes and get event objects sent to the callback. Essentially scope is much easier to handle. But that’s another story.
You can read more about the Delegate class and components at Actionscript.org.






