Buttonology: A Walkthrough of Button Making Methods
How you approach a problem is to some extent your key to accomplishing good solid work. This walkthrough will guide you in the six most commonly used methods for button creation and show you in which situations they are best put to use.
The Button Making Dilemma
Let me tell you a little story about how all of this button interaction conflict started. One day Adam and Eve were out in the Garden of Eden.
ADAM: Hey Eve, you look different today, what’s wrong?
EVE: I’m really thirsty, and we don’t have fresh water anymore.
ADAM: Stay right here.
Adam went to a near by vending machine, saw an apple juice box, memorized its number, inserted a coin and pressed the button! Nothing happened. There was a bug.
You see, Adam started an event that should have triggered an action. Luckily, being a well versed ActionScript programmer, he plugged his USB ActionScript compiler into the vending machine’s USB ActionScript programming slot and started to debug the code.
He had a shape lying on the stage that looked like a button, and nothing else. Someone had forgotten to make the code. It was now up to him to find the most appropriate method to approach this problem and code his way to the juice box.
Old School Method
When you first open Flash 5 you’re prompted to view a few tutorials if you wish. One of these tutorials teaches you how to make simple button interaction and for the most part of your ActionScript 1 and beginning 2 you follow that path.
It works something like this:
- Create a button symbol.
- Inside the symbol set the states you want the button to have.
- Go to the timeline where you put the button, click to select it, open up the actions and write:
on(press){
trace("hihi that tickles");
}







Hi there and thank you for tne nice article.
Ps: i like using mc based buttins since it’s easyer to animate their different states.
Have a nice year too.
I’m missing a piece of the puzzle in method 5, could you elaborate on the code you use on the main timeline. How do you tell your movieclip to copy the behaviour of the class?
As you saved your files in the latest version of flash I can’t open the files in CS3 to figure it out myself.
tnx
button should have instance name of “myMovieClip” and be on the stage. Then you just specify DocumentClass to “Main”
There should be mc with instance name of “myMovieClip” on the stage, and then just set DocumentClass to “Main”.
Nice overview. In the final AS3 example, I’m not sure if it makes sense to call the document class “MyButton.as” as document classes usually do more than just set up buttons. That might confuse people.
It might also be good to point out that as you add more buttons, it won’t be good practice to hardcode them as b1, b2, b3, etc. If there are a lot of buttons that look similar or do similar things, they should probably be stored in array that can be iterated through or they should be linked to a single custom button class or routed through a common “createButton” function. If the buttons all function in pretty different ways and look different from each other, then the above may not apply, but they should at least be named uniquely so that it’s easy to identify which is which.
I undestand your point, but in this example that button class only relates to the button component, so calling it Main, could be misleading, as it could suggest it did more, or not, i belive this is quite subjective, the way you name your document class, the way i’m used to is to name it either Main.as or the name of the main FLA.
Naming conventions are indeed a must, Peter Elst has a cool checklist about best practices, naming is one.
i suggest everyone to take a look into it. http://www.peterelst.com/blog/2007/02/08/best-practices-checklist/ , he also gave a cool best practice workshop at ADOBE MAX 2008 in Barcelona. couldn’t find the pdf, but i’m sure its out there somewhere,
thanks for the feedback and clarifying some points that could have been confusing,
cheers
Nice walkthrough. I’ve mess with all of these at some point and slowly have evolved to AS3. I’d love to see someone show how to dynamically create buttons with text labels and gradient fills. I’ve done something like that myself, but it’s still a work in process.
Good job!
Stay tuned ! In a couple of weeks we’ll have “The fall of Babylon: how AS1.0 became AS 2.0.
)
And later, in a special documentary:
)
The Gregorian Calendar, or “How I learned to code a Timer Object”
I love the story !!!
Nice tutorial, but someone is missing a point here, and I don’t know whether it’s me or the author.
If I’d like to reuse any of the examples, the only thing that I have to do for my new code to work is to change the button instance name, so…
I can’t understand how exactly the “class” (ex.6) code is more reusable than the timeline code (ex.4).
I’ll try to elaborate a bit better.
These are very simple examples of interaction, and in all cases you can copy and paste them, justmake sure you have the instanced symbol object with the same name being referenced in the code.
However programming in the timeline makes your code more dispersed and therefore harder to reuse it unless you start copy pasting all over the place on other projects. take a scrollbar for exmaple: if you add the code to the timeline you will always have to copy paste it wherever you want to add a scrollable text, but instead, if you used a base class that did all the math for you, you could easily just instanciate a new Scrollbar class. This comes in handy not only because you can reuse the code, but also because its easier to update, since you only need to update one class, and your code is stored in one place making it easy to access.
Going back to the tutorial scenario. Example 6 is totally reusable and will add a b1 instance to every project, or symbol it gets called to, using always the same .as.
In example 4 you would need to copy and paste that code everytime you needed. If there was a bug, it would be a pain to correct depending on how many times you copied it.
hope this helps you understand why timeline can be more confusing then packages when it comes to updates and reusability.
Ok. I understand what you mean
But If I’m a tidy programmer and I don’t disperse my code on different movie clips and I keep all my code on a single frame, the reusability should be pretty similar on both methods
yes, but in more complex structures or bigger projects you may end up with 1000+ lines of code in a single frame, and browsing trough that code could be a pain as well.
Ultimately its about being comfortable with the method you choose that really counts
Cheers