Tutorial: Understanding Classes in AS3 Part 3

In this tutorial, learn how to identify when a chunk of code should be spun off into its own .as Class file.

Trial by Flash

This series of Understanding Classes tutorials chart my progress through unfamiliar Actionscript 3.0 territory. i am a designer-turned-coder, so everything i understand about code was learned in the School of Hard Knocks … most often while a producer breathed down my neck and i had two weeks to program a game using concepts i didn’t grok.

Sgt. Slaughter

Grokking is Half the Battle

i had already learned to avoid “spaghetti code”, a common newbie Flash developer habit where you stick little bits of code on various MovieClip symbol instances and frames throughout your Flash movie. The next step was to round up all of those little bits of spaghetti code and confine it all to the first frame of my Flash movie.

Baby w/ spaghetti

Don’t spaghetti code. Think of the children.

The next leg of the journey into Actionscript 3.0 was to escape the first frame, and to move all of that first-frame code into its own seprate .as Class file. That’s where Understanding Classes began. It seemed like a pointless step – whether the code was in its own frame or in its own Class file seemed like picky Egghead semantics.

The fuzzy picture came more clearly into focus with the next Understanding Classes tutorial, where we learned to write a custom Class to represent symbols in the Flash library. We used the less-than-helpful example of a Dog Class to explain how to pull this off.

Retarded Dog

Thanks for nothing, DOG.

But the time for theory is over. If we’re going to finally learn how to take full advantage of Object Oriented Programming, we need to look at some real-world examples. In this tutorial, we’ll pick through that glob of code in our Main.as file and find places where it makes sense to group chunks of functionality and split them off into their own Class files.

It’s Apparent You’re A Parent

In order to understand when and where to create new Classes, you almost have to think like a parent. All of the methods (things a Class can do) and properties (things a Class is) are your children. As your children grow older, you want them to learn how to take care of themselves. You (hopefully) don’t want to be changing your son’s diapers when he’s 17 years old.

Baby Huey

Worst. Cartoon character. Evar.

So when you look at that mess of code in your Main.as Class, start asking yourself this question: should this kid, this group of properties and methods, be taking care of himself? Is this stuff that me, the Main.as Class, should be doing, or is this something that this kid can go off and do by himself?

Huh?

Here’s a real-world example:

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
	import flash.events.MouseEvent;

	public class Main extends MovieClip
	{
		public function Main()
		{
			var myButton:MovieClip = new MyButton();
			myButton.label_txt.text = "Play";
			myButton.addEventListener(MouseEvent.CLICK, clickMyButton);
			myButton.addEventListener(MouseEvent.MOUSE_OVER, rollOverMyButton);
			myButton.addEventListener(MouseEvent.MOUSE_OUT, rollOutMyButton);
			myButton.mouseChildren = false;
			addChild(myButton);
			myButton.x = 150;
			myButton.y = 89;
			
		}

		public function clickMyButton(e:Event = null):void
		{
			playGame();
		}

		public function rollOverMyButton(e:Event = null):void
		{
			var myButton:MovieClip = MovieClip(e.target);
			myButton.background.gotoAndStop("highlight");
		}

		public function rollOutMyButton(e:Event = null):void
		{
			var myButton:MovieClip = MovieClip(e.target);
			myButton.background.gotoAndStop("unhighlight");
		}

		public function playGame():void
		{
			// Do some stuff here
		}
	}
}

In this piece of code, the Main.as file adds an instance of the MyButton Class to the stage. When the player clicks the button, we fire the playGame method.

There are some things here that the Main.as Class should probably do, and a bunch of things that the LabelButton Class should do for itself. Let me ask you this: why on God’s green Earth should Main.as care about how the MyButton Class implements all of its MouseEvent code? Making the button highlight on rollOver is MyButton’s responsibility, not Main.as’s responsibility.

Rollover

Take care of your own rollover.

Let’s imagine a not-too-distant future. Robots rule the Earth. Gary Coleman is in the White House. And you’re writing a new Actionscript project where you need a MyButton. The way you’ve written it here, can you easily pluck your MyButton Class out of this old project, and plunk it into your new project and expect it to work? No! That’s because you have code that is crucial to the functioning of your MyButton class outside your MyButton Class.

Do the clickMyButton, rollOverMyButton, and rollOutMyButton methods belong to Main, or do they belong to MyButton? Let’s go back to our semi-useless Dog example. Do bark, sniff and peeOnLeg belong to Main, or do they belong to Dog? They belong to Dog. So let’s put them in Dog.

Fat Dog

Stuff everything concerning Dog IN Dog.

Here’s the above script with the MyButton-specific methods removed:

package
{
	import flash.display.MovieClip;
	import flash.events.Event;

	public class Main extends MovieClip
	{
		public function Main()
		{
			var myButton:MovieClip = new MyButton();
			myButton.label_txt.text = "Play";
			addChild(myButton);
			myButton.x = 150;
			myButton.y = 89;
			
		}

	}
}

Wow! We really cleaned up our Main Class, didn’t we?

Here’s what our MyButton Class looks like. We’ve just plucked the methods out of our Main Class and put them where they belong, in MyButton. MyButton changes its own diapers.

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
	import flash.events.MouseEvent;

	public class MyButton extends MovieClip
	{
		public function MyButton()
		{
			addEventListener(MouseEvent.CLICK, clickMyButton);
			addEventListener(MouseEvent.MOUSE_OVER, rollOverMyButton);
			addEventListener(MouseEvent.MOUSE_OUT, rollOutMyButton);
			
		}

		public function clickMyButton(e:Event = null):void
		{
			playGame();
		}

		public function rollOverMyButton(e:Event = null):void
		{
			background.gotoAndStop("highlight");
		}

		public function rollOutMyButton(e:Event = null):void
		{
			background.gotoAndStop("unhighlight");
		}

		public function playGame():void
		{
			// Do some stuff here
		}

	}
}

If you’re keen-eyed, you’ll notice that we were even able to cut down the code when we moved it to the MyButton Class. Instead of saying myButton.addEventListener(MouseEvent.CLICK, clickMyButton);, we can drop the “myButton” part and just say addEventListener(MouseEvent.CLICK, clickMyButton);. That’s essentially the same as saying this.addEventListener(MouseEvent.CLICK, clickMyButton);. The “this” keyword is like saying “me”. We’re inside the MyButton world, so we’re referring to ourselves. While we are writing code inside the MyButton class, we are MyButton.

Starting an Argumemt

Now what about that line in Main.as where we label the button?

myButton.label_txt.text = "Play";

Is labelling the button a responsibility of Main.as, or a responsibility of MyButton.as? The answer is slightly tricky.

MyButton might not always be labelled “Play”. We could (and should) think generically, so that MyButton could be labelled “Play” or “New Game” or “Change Character” or whatever. So Main.as should be responsible for labelling the button, right?

Not exactly. MyButton should still be responsible for labelling itself. But Main.as should be responsible for deciding what that label says. That way, Main could create buttons that say “Play”, “New Game” and “Change Character”,all using the same MyButton Class. The MyButton Class takes care of all the logic of actually displaying that text on itself.

To pull this off, we pass a parameter to our MyButton Class from Main.as.

package
{
	import flash.display.MovieClip;
	import flash.events.Event;

	public class Main extends MovieClip
	{
		public function Main()
		{
			var myButton:MovieClip = new MyButton("Play"); // Check it out!!!
			addChild(myButton);
			myButton.x = 150;
			myButton.y = 89;
			
		}

	}
}

Main.as creates a new MyButton instance (stamp, copy), and passes something called a parameter to the MyButton Class. MyButton grabs that parameter and uses it to label itself.

Note: if you’re fuzzy on the concept of datatypes (String, Number, Int, Boolean, etc), you may already be in over your head. Go read a basic tutorial on datatypes, and come on back.

Here’s the MyButton Class, now modified to grab that parameter from Main.as (or whatever Class instantiates [makes a stamp of, makes a copy of] the MyButton class).

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
	import flash.events.MouseEvent;

	public class MyButton extends MovieClip
	{
		public function MyButton(labelName:String)
		{
			label_txt.text = labelName; // Grab that parameter and label myself!

			addEventListener(MouseEvent.CLICK, clickMyButton);
			addEventListener(MouseEvent.MOUSE_OVER, rollOverMyButton);
			addEventListener(MouseEvent.MOUSE_OUT, rollOutMyButton);
			
		}

		public function clickMyButton(e:Event = null):void
		{
			playGame();
		}

		public function rollOverMyButton(e:Event = null):void
		{
			background.gotoAndStop("highlight");
		}

		public function rollOutMyButton(e:Event = null):void
		{
			background.gotoAndStop("unhighlight");
		}

		public function playGame():void
		{
			// Do some stuff here
		}

	}
}

Beautiful! In this line, we accept a parameter:

public function MyButton(labelName:String)

And in this line, we grab that parameter and use it to label ourselves:

label_txt.text = labelName; // Grab that parameter and label myself!

Jockeying for Position

Finally, we’ll talk about the x/y lines in the Main Class:

myButton.x = 150;
myButton.y = 89;

Is that something that Main should be responsible for, or something that MyButton should be responsible for? x and y are properties of MyButton, so MyButton should handle them, right?

Not so fast! While we could let MyButton position itself, it wouldn’t make sense to. The Class that needs a MyButton should decide where on the screen the button should go. Otherwise, every time we create a new MyButton instance, it’ll appear in the same place on the screen. Not so hot. Main.as should take care of positioning the button instance.

Real Ultimate Power

Et voila! We’re in good shape now. We’ve:

  1. Identified a chunk of code that should change its own diapers
  2. Moved that code to its own .as Class file
  3. Thought generically about how an instance (stamp, copy) of that Class should be treated

Now, check out the glorious wonderland we can experience and enjoy:

package
{
	import flash.display.MovieClip;
	import flash.events.Event;

	public class Main extends MovieClip
	{
		public function Main()
		{
			// Instantiate a new play button:
			var myPlayButton:MovieClip = new MyButton("Play");
			addChild(myPlayButton);
			myPlayButton.x = 150;
			myPlayButton.y = 89;

			// Instantiate a new instructions button:
			var myInstructionsButton:MovieClip = new MyButton("Instructions");
			addChild(myInstructionsButton);
			myInstructionsButton.x = 210;
			myInstructionsButton.y = 89;

			// Instantiate a new credits button:
			var myCreditsButton:MovieClip = new MyButton("Credits");
			addChild(myCreditsButton);
			myCreditsButton.x = 340;
			myCreditsButton.y = 89;
			
		}

	}
}

Wowee! THREE new button instances in half the code it took to have ONE button when we first started out.

We’re almost out of the woods. But there’s one nagging thing remaining. Notice that we have a method in the MyButton Class that looks like this:

public function clickMyButton(e:Event = null):void
{
	playGame();
}

Should MyButton decide what happens when it gets clicked? We saw that the Main.as Class can quickly create three instances of MyButton – a Play button, an Instructions button, and a Credits button. These three buttons are all going to do different things when the player clicks them. So the generic MyButton Class cannot possibly define its own click behaviour. Main.as is going to have to decide.

Let’s yank that click code right out of the MyButton Class:

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
	import flash.events.MouseEvent;

	public class MyButton extends MovieClip
	{
		public function MyButton(labelName:String)
		{
			label_txt.text = labelName; // Grab that parameter and label myself!

			// this is where the MouseEvent.CLICK listener used to be

			addEventListener(MouseEvent.MOUSE_OVER, rollOverMyButton);
			addEventListener(MouseEvent.MOUSE_OUT, rollOutMyButton);
			
		}


		public function rollOverMyButton(e:Event = null):void
		{
			background.gotoAndStop("highlight");
		}

		public function rollOutMyButton(e:Event = null):void
		{
			background.gotoAndStop("unhighlight");
		}

	}
}

And instead, we’ll write the listener for each button’s MouseEvent.CLICK in the Main.as Class:

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
	import flash.events.MouseEvent;

	public class Main extends MovieClip
	{
		public function Main()
		{
			// Instantiate a new play button:
			var myPlayButton:MovieClip = new MyButton("Play");
			myPlayButton.addEventListener(MouseEvent.CLICK, clickBtnPlay); // new line!
			addChild(myPlayButton);
			myPlayButton.x = 150;
			myPlayButton.y = 89;

			// Instantiate a new instructions button:
			var myInstructionsButton:MovieClip = new MyButton("Instructions");
			myInstructionsButton.addEventListener(MouseEvent.CLICK, clickBtnInstructions); // new line!
			addChild(myInstructionsButton);
			myInstructionsButton.x = 210;
			myInstructionsButton.y = 89;

			// Instantiate a new credits button:
			var myCreditsButton:MovieClip = new MyButton("Credits");
			myCreditsButton.addEventListener(MouseEvent.CLICK, clickBtnCredits); // new line!
			addChild(myCreditsButton);
			myCreditsButton.x = 340;
			myCreditsButton.y = 89;
			
		}

		public function clickBtnPlay(e:Event = null):void
		{
			// Play the game
		}

		public function clickBtnInstructions(e:Event = null):void
		{
			// Show the instructions
		}

		public function clickBtnCredits(e:Event = null):void
		{
			// Show the credits
		}

	}
}

And there you have it. The MyButton Class takes care of its own diapers. It labels itself based on a parameter that’s passed to it. It handles its own rollOver and rollOut events. Main.as takes care of creating instances (stamps, copies) of the MyButton Class. Main.as decides:

  • What the button label will say
  • How the button will be positioned on the screen
  • What the button does when clicked

The First of Many

That’s a real-world example of where and when it makes sense to collect your code in a separate Actionscript Class file. Of course, this is just one example in an endless sea of possiblilities. The general rule is that if the code should be changing its own diapers, it should be in its own Class file. And if the code can be written generally so that it can be re-used, you’re ahead of the game.

The mystery that springs up from all of this is the OOP rule of Encapsulation, which states that you should write your Classes so that they’re self-contained and self-reliant. Not only do they change their own diapers, but they rent their own apartment and cook meals for themselves, with no reliance on outside Classes whatsoever to live.

There are advantages and disadvantages to Encapsulation, which we can look at in our next Understanding Classes tutorial. The biggest disadvantage is that to create a truly encapsulated Class, you have to write an ASSLOAD of repetetive Actionscript 3 code. i’ll show you a cheat that’ll break the encapsulation rule, but will save you HOURS of coding. The Eggheads will have my head for it, so let’s just keep it between you and me.

For more tips, tricks and tutorials on Flash and Actionscript, check out our Flash and Actionscript 911 feature.

27 thoughts on “Tutorial: Understanding Classes in AS3 Part 3

  1. Mark

    Nice tutorial. I was having problems with the classes communicating with each other. This seems really simple. I thought there would be import statements to pull all the classes in and things like that. Thanks for putting this all down.

    Reply
  2. Ryan

    Thanks, Mark. No need to get fancy with import statements, unless you’re referring to Classes that are in other folders. If everything’s just mashed into the same folder and exists in parallel, you can get away with just instantiating Classes as normal.

    Of course, when your project gets larger, it won’t do to have piles of Classes jammed together in a single folder. That’s why an upcoming Understanding Classes tutorial (probably part 5) will deal with import and package statements. They confused the Hell out of me at first, but i think i’m finally catching on.

    Reply
  3. Logan

    is it correct to still be referring to myButton?

    for example shouldn’t this:

    	// Instantiate a new credits button:
    	var myCreditsButton:MovieClip = new MyButton("Credits");
    	myCreditsButton.addEventListener(MouseEvent.CLICK, clickBtnCredits); // new line!
    	addChild(myCreditsButton);
    	myButton.x = 340;
    	myButton.y = 89;
    

    actually be changed to this?:

    	// Instantiate a new credits button:
    	var myCreditsButton:MovieClip = new MyButton("Credits");
    	myCreditsButton.addEventListener(MouseEvent.CLICK, clickBtnCredits); // new line!
    	addChild(myCreditsButton);
    	myCreditsButton.x = 340;
    	myCreditsButton.y = 89;
    
    Reply
  4. Social

    When you say:

    ” Main.as should take care of positioning the button instance. ”

    Why can’t you do something like this:

    In the button class:
    public function AppButton(LabelText:String,Xposition:Number,Yposition:Number)

    and then in the Main function:
    var stop_Button:MovieClip = new AppButton(“Stop”,150,50);

    Is that wrong?

    Reply
    1. Ryan

      Social – IMO, that’s not “wrong” at all. It’s a very valid approach, especially if you want to smoosh your code a little.

      Reply
  5. fallenSkillz()

    Wow, I’m still stuck in the monkey evolution era…Soooh do I need to do this for every moviEcliP on my lybrary?? (just ignore me still learning how to write ” (); ” Oh and by the way your tutorials are funny, laughter and learning is the shitznitzz . I enjoyed reading it..and I like your site design…carry on ..ThankYou();

    Reply
    1. Ryan

      fallenSkillz() – the good news is that no, you don’t have to link every single clip in your library – just the ones that sorta go hand-in-hand with the Classes you’ve written. So imagine you have a ControlPanel Class that describes the actions of some play/pause/stop/mute buttons, and you make a Clip in your library called ControlPanel. The ControlPanel movieclip has movieclips inside it – btnPlay, btnPause, btnStop and btnMute. You add the linkage name “ControlPanel” to the ControlPanel clip in your library.

      When you say this:

      // This is some code you'd write somewhere OUTSIDE the ControlPanel Class:
      var myControlPanel:ControlPanel = new ControlPanel();
      addChild(myControlPanel);
      

      … you not only get an instance of your ControlPanel movieclip from the library on your stage, but it’s also being controlled by the ControlPanel Class that you wrote.

      You DON’T have to give linkage names to btnPlay, btnStop and all the others. They’re nested inside the ControlPanel clip. The ControlPanel Class can just talk to them, because it’s sorta been glued to the ControlPanel clip.

      // This is some code you'd write INSIDE the ControlPanel Class:
      btnPlay.addEventListener(MouseEvent.CLICK, doPlay);
      btnStop.visible = false;
      

      As long as those button clips have instance names, you’re good to go.

      Did that answer your question?

      Reply
  6. No0B

    That very last comment Ryan is crucial and perhaps it should be in bold to emphasise its importance to beginners.

    “As long as those button clips have instance names, you’re good to go.”

    By giving movieClips an instance, they are accessible by the doc class WITHOUT declaring them using:

    var mySquare:MySquare= new MySquare();

    Instead you can just use MySquare.x=300; for example straight off the bat, because the stage already has an instance and the complier knows it’s alive and breathing OOP rocket fuel.

    Hope i’m right, as i’m just learning AS3 myself and your tuts are EXCELLENT :))))))))))))))))))))))

    Thank you.

    Reply
    1. Ryan

      Thanks so much, NoOB. There are three places where you can identify MovieClips, and it’s crucial to know the difference:

      The SYMBOL NAME in the library. This is when you punch F8 or “Convert to MovieClip” and are asked to enter a name. This is how the symbol is identified in the Library. This name is FOR YOUR EYES ONLY. Actionscript cannot see this name or do anything with it. When i work with students, i like to use “monkey butt’ or something similarly ridiculous just to emphasize that this name is not important to your code.
      The INSTANCE NAME. Since you can drag numerous copies of your monkey butt symbol out of the library and onto the stage, we need to give each one a name on the stage so that we can refer to them with code. A typical example is “ball0″, “ball1″, “ball2″ etc.
      The LINKAGE NAME. We don’t have to “physically” drag an instance of a symbol out of the library – we can do it with code. But like we said, code can’t see our linkage name “monkey butt”. We have to give the symbol a special linkage name or tag so that we can refer to things in the library via code.

      This is a very easy place to get tripped up when you’re just starting out. Be aware of these THREE ways of naming, and the difference between each, and you’ll be a big step ahead.

      Go forth and code.

      Reply
  7. No0B

    Thanks for the explanation Ryan, great stuff.

    I guess it’s like Photoshop, where there are many ways to do the same thing but each has it’s own subtle purpose; easy to get confused for beginners, but it will slowly make sense :)

    As a side note, may i ask you what you think of Flex Builder 3? Is it better to use Flash IDE for graphics and Flash Develop for AS3 OR do it all in Flex Builder, which seems a bit clunky and is a Visual Studio rip-off. BTW, VS is the best IDE on the market, simply superb for C#, VB, C++ development.

    Reply
  8. AntiFaith

    Thanks for this explanation of classes – its helping me get my head around them a lot quicker than i would have, so much Kudos! However i’ve got a minor problem…

    i’ve set this up by copying and pasting your code straight into flash – sorted out a couple of errors within it – yet when i Test the Movie it says access of undefined property label_txt which is just a pain in the arse tbh lol any ideas? Bearing in mind my code is pretty much EXACTLY the same as yours lol – thanks for any help bro

    Reply
    1. Ryan

      AntiFaith – it’s not really meant to be a cut n’ paste practical exercise. It’s more theoretical, because the code’s not that interesting.

      You’re getting that error because you don’t have a MovieClip class in your library called MyButton with a dynamic text field inside it with the instance name “label_txt”. i copy/pasted the code and ironed out a few type-os, then added “myButton.mouseChildren = false” to prevent an error in that initial block of code. Everything should work now.

      Reply
  9. David of Neptronix

    Oh dude, thanks a bunch for putting this up. I am making the leap from actionscript 2 to 3 and have found your tutorials extremely useful. I feel like i get it, whereas everything else i’ve read kind of kept me in the dark..

    Reply
  10. Pingback: BJPcommunication.com» Archives » Tutorial sur les classes AS3 et la POO

  11. Luthimir

    My first thought upon reading this was that you could also incorporate one listener for all of your buttons:

    //in Main function
    myPlayButton.addEventListener(MouseEvent.CLICK, clickBtn);
    myInstructionsButton.addEventListener(MouseEvent.CLICK, clickBtn);
    myCreditsButton.addEventListener(MouseEvent.CLICK, clickBtn);
    
    //clickBtn function checks for event target
    public function clickBtn(event:Event):void
    {
    	switch (event.target)
    	{
    		case myPlayButton:
                              //play game stuff
                              break;
                    case myInstructionsButton:
                              //etc...
    	}
    
    }
    

    A question – why do you use e:Event = null? I am not familiar with this concept, I’ve always used the technique I posted above (event:Event… without the = null).
    (Side note, not familiar with how to format my code on this site, sorry if it’s hard to read)

    Reply
    1. Ryan Henson Creighton

      No problem, Luthimir – i usually go in to readers’ comments and add the formatting for them.

      When you set the value of a parameter, you’re creating an “optional argument”. It’s a way of setting a param to a default value if nothing gets passed in. Say, for example, you had this method:

      private function eatSomeWieners(numberOfWieners:int = 2)
      {
      }
      

      Both of these calls will now work:

      eatSomeWieners(57);
      eatSomeWieners();
      

      Normally, if a method wants an argument, you gotta pass it an argument. But note that if we have an optional argument, you don’t have to. Keep in mind that if you use these optional arguments, ALL of your optional arguments have to be listed in the method signature AFTER all of the compulsory arguments.

      So e:Event=null enables us to just fire the button click function without having to pass it an event. Maybe you want to do what the button does, but it’s not in response to a user’s click? That’s what that’s all about.

      Reply
  12. Malono

    Hi,
    Experimenting with classes found your tutorials and did this with it. Please shoot on it. Why its better , or why its worse. Trying to learn classapproach.

    package
    {
    import flash.display.MovieClip;
    import flash.events.Event;
    import flash.events.MouseEvent;

    public class Main extends MovieClip
    {

    public function Main()
    {
    // Instantiate a new play button:
    var myPlayButton:MovieClip = new MyButton(“Play”,0,89);
    addChild(myPlayButton);

    // Instantiate a new instructions button:
    var myInstructionsButton:MovieClip = new MyButton(“Instructions”,200,89);
    addChild(myInstructionsButton);

    // Instantiate a new credits button:
    var myCreditsButton:MovieClip = new MyButton(“Credits”,400,89);
    addChild(myCreditsButton);

    }
    }
    }

    //MyButton Class
    package
    {
    import flash.display.MovieClip;
    import flash.events.Event;
    import flash.events.MouseEvent;

    public class MyButton extends MovieClip
    {
    public function MyButton(labelName:String, xPosition:int, yPosition:int)
    {
    label_txt.text = labelName; // Grab that parameter and label myself!
    x = xPosition;
    y = yPosition;

    addEventListener(MouseEvent.MOUSE_OVER, rollOverMyButton);
    addEventListener(MouseEvent.MOUSE_OUT, rollOutMyButton);
    this.name = labelName;

    if (name == “Play”) {
    addEventListener(MouseEvent.CLICK, clickBtnPlay);
    }
    else if (name == “Instructions”) {
    addEventListener(MouseEvent.CLICK, clickBtnInstructions);
    }
    else {
    addEventListener(MouseEvent.CLICK, clickBtnCredits);
    }

    }

    public function rollOverMyButton(e:Event = null):void
    {
    gotoAndStop(“highlight”);
    }

    public function rollOutMyButton(e:Event = null):void
    {
    gotoAndStop(“unhighlight”);
    }
    public function clickBtnPlay(e:Event):void
    {
    // Play the game
    trace(“Play the game”);
    }

    public function clickBtnInstructions(e:Event):void
    {
    // Show the instructions
    trace(“Show the instructions”);
    }

    public function clickBtnCredits(e:Event):void
    {
    // Show the credits
    trace(“Show the credits”);
    }

    }
    }

    Tried to make it more generic by adding the function as a 4th parameter, failed though. Tried to pass it as String and then converting the received String to a function….
    Something like this in myButton class…
    var myStringConvertedToFunction:Function = function(clickFunction);
    But couldnt get that working…

    Regards,
    Malono

    Reply
  13. taran

    awesome tutorial, been trying to get my head around classes and how to use them and i finally get it ! why is adobe documentation so pants! I prefer your tutorials here.

    Reply
  14. TaNzU

    You really have some KICKASS tutorials!!! have to say that this is the best there is!! you teach kazillion times better than my flash teacher in my “real” school! I approciate it so much, learned so much from untold!!! :D

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>