Have you ever been working on a project where you’re writing some Actionscript and you think to yourself, “I know I’ve done this before. Where is that code. It’s in an FLA around here somewhere . . . ”

That problem is one of the things that object oriented programming is good at solving. It helps you externalize your code and organize it so that you can reuse those common bits over and over.

Thus far the classes that we have created in parts 1 and 2 have been written in .as files sitting in the same folder as your FLA. Sometimes that’s okay because those classes might be pretty specific for the project you are working on. But what if you have written some methods that could be really useful for other projects. You don’t want to have to copy that .as file to other folders just to use it.

The Flash authoring tool gives you a way of putting your commonly used class files in one location that can be accessible to all of your FLAs. No matter where they are on your computer.

Here’s what you need to do:

1. Open the Flash authoring tool
2. From the menu bar select Edit -> Preferences
3. Select Actionscript from the Category nav on the left
4. Click on the Actionscript 2.0 Settings button
5. Click the “+” button to add another Classpath [see image below]
6. Now click the target button - it’s the one in the center. This will allow you to browse to the folder where you’re going to put your classes.
   • Note: this is a very important folder. You don’t want to put it somewhere where it could accidentally be moved or deleted.
   • However, you want to be able to get to it easily. Plus, you might need to zip the files up in this folder to send to other people.
   • Remember, you cannot publish your FLA if you don’t have your class files. So if you’re working on a project with someone else you will need to share the files in this folder with them.
7. All done? Click Ok

You can see that my Classpath is : C:\Documents and settings\polyGeek\Desktop\FlashSpace\GlobalClasses

Now that we can write reusable code what should we do first? One of the things that I have to do in just about every project is load external images and SWFs. If you’ve done this yourself you realize it’s a bit of a pain. You have to create listeners, and functions, and all sorts of things. I think it would be great if we had a utility that could handle all this for us.

Here’s the code below for a utility that I have written to make it easy to load external assets into your SWF. A detailed explanation of how to use it follows.

First off take a look at line 14.

class com.polygeek.utils.Holtzman {

That’s a bit different from what you’re used to in creating classes thus far. What’s up with that?

Suppose you wrote a class, we’ll call it, FlashUtils. You put it in your global classpath and use it on a number of your projects. Everything works just fine until you download someone’s class that does some really cool stuff but its name is also FlashUtils. Now what?

Now you know that you can’t change the name of your class because then you would have to go back to every project that uses it and change the name there as well. And you don’t want to mess with someone else’s code.

The solution is that everyone puts there classes in a unique namespace. One thing you can be sure of that is unique is an internet domain name. So my global classes are in com.polygeek. Everything that comes after that are for my own organizational purposes. The Holtzman class is on the folder utils because it’s a utility.

Another thing to note is that classes are given names that reflect their purpose. You might be wondering what Holtzman is. If you hadn’t guessed by now I’m a geek and being a geek I like to chose geeky names for things. Is it consistent with best practices? Maybe not but that’s what you get for learning object oriented programming from a philosophy major. :-)

Back to using this Holtzman class. Go to your global class path that you set up from above and create a sub folder named com. And inside of that create a folder named polygeek. And once more for the utils. Notice that all the folder names are lower case which is consistent with best practices - sometimes I do things right.

Now create an .as file named Holtzman and paste the code from above into it.

Here’s how you use the class.

Create an FLA and paste the code below into it.

Publish and you should see two images - the polyGeek logo - one rotated +15 degrees and the other -15 degrees. And one of them has smoothing turned on. You can see that if you resize or rotate an image you probably want to use smoothing.

Here’s a quick synopsis of what’s happening:

1. When you instantiate the Holtzman class you pass, at a minimum, the MovieClip to load the image into and the path to the image/swf.
2. If you would like to do something like resize the image you have to wait until it has completed loading. That’s what the onImageLoaded function is for. You can name that function anything you like.
3. Any parameters passed to the Holtzman class, after the smoothing: true/false, will be attached to the external asset you loaded so that you can access them in your callback function. That’s useful if, for instance, you are loading a series of images and you want to rotate each one a different amount. You can make up a variable name, like rotateThisMuch, and then the value you want to rotate to.
4. The callback function you specify receives on Object of type MovieClip. That MovieClip will have a property of rotateThisMuch with the value you specified in the next parameter. This is an added feature that you probably won’t need very often but when you do it comes in very handy.

The great thing about all this is that you don’t have to understand any of the code inside the Holtzman class to use it. All you need to know is how to instantiate it - lines 16-20 and 22-26 - and what parameters to pass to it.

Word of warning: when you create a class that gets used across projects you have to resist the urge to modify it. For example, if you changed the order in which the class accepts parameters then all the places where you used it before would be broken.

Also notice that when you accessed the Holtzman class you did so through the constructor. Meaning your instantiated the class to create a new object. In this case it’s rather trivial but that is a new object and so you’ve now done object oriented programming.

Congratulations.

I would now suggest that when you feel comfortable with what you’ve learned to this point that you read Colin Moock’s book: Essential Actionscript 2.0. It’s pretty much the definitive source of learning OOP in Actionscript.

In part 4 I’ll give you my two-cents on weather or not to start learning Actionscript 2.0 or Actionscript 3.0 first.