Read an Excerpt
Chapter 1: Starting OutIn this first chapter I'll introduce you to a little programming theory. But don't worry - it'll be just enough to get you started with an understanding of important terms. We'll end the chapter with a look at how even two lines of ActionScript can give you some basic interactivity. Coding already in Chapter 1? Yeah it's not as bad as you think...
You think of ActionScript, you think of interactivity, you think of the user reacting to your site and making things happen. That's why we're here isn't it? - to add that interactive power to your designs? For Flash, this interactivity is made up of events and the instructions that it's given on how to react to them. These events are the first of our programming building blocks.
Events and How to Handle Them
When I was a child, I was given a cuckoo clock as a present. Well, actually, a cuckoo clock only in the loosest sense of the word, given that it was in the shape of a cartoon lion with a swinging tail as a pendulum. Every time the clock struck the hour, the lion would wake up, open its mouth and growl. He could act as an alarm clock too, giving an almighty roar as the alarm went off. The point of this reminiscing is to introduce you to one of the basic building blocks of ActionScript: events.
As I've said, there were two things that set my lion into action:
When the clock reached the beginning of the hour, it was time to growl. When the alarm time arrived, it was time to roar.
These were the two events that the lion was waiting for. As soon as either event occurred, the lion would perform the appropriate action. ActionScript is called an event-driven language, which soundscomplicated programing-speak until you realise that, just like the lion, it's set up to wait for something to happen. It reacts to events - nothing more comlplicated than that.
So what is a Flash event?
It can be something obvious that happens externally, say the user pressing a button on your web site or typing on the keyboard. An event can also be something less obvious that happens internally within the Flash engine room, like loading a movie clip or moving to the next frame. When Flash moves to the next frame, it will look to see whether there are any instructions attached to it and run them accordingly. This is called an internal event because Flash generates it on its own.
Whether it's dealing with an internal or external event, Flash ActionScript follows the same pattern:
1. ActionScripts are set up to detect a particular event.
2. Once the event occurs, a set of ActionScripts is executed to handle that event.
The ActionScript that kicks into action in step 2 is sometimes referred to as the event handler and always forms a pair with the main event. So, that's the first rule of ActionScript: if you have an event, you must have an event handler.
In the real world, you can see all sorts of event/event handler pairs around you. For example, your electric kettle waits for the water to start boiling (the event) and has a special circuit that switches the power off (the event handler) when this occurs. Or your central heating: you set your thermometer to a certain temperature. When it gets that cold in your apartment (the event) your heating kicks in (the event hander) to make things warm and toasty again.
This event/event handler relationship is easy to identify when we're talking about something like buttons, but the event isn't always obvious when Flash is generating it itself in the background. However, if you have this basic understanding-that events always have a corresponding event handler - it will make the discussions we have later in this book as we delve deeper into ActionScript a lot easier.
Whether you're new to this programming business or even if you've already had experience of other languages like BASIC or Pascal, you're probably not familiar with the event/event handler structure. You may be saying "OK, you've told us what each half of the pair does, but why do we use them? What are the advantages?"
One strength that event-driven ActionScript brings to Flash is the ability to react to the unexpected as soon as it occurs, or in real-time. I'll explain in a little more detail.
Programming languages like BASIC work well on problems where there is a well-defined path. A program that calculates your grocery bill at the checkout goes along the same path in the same order every time:
1. All the prices are keyed in
2. The computer adds them up
3. The screen shows your total bill
Step 3 can happen only once 1 and 2 are done.
Unfortunately, real life isn't so easy. When we're actually buying the items on the grocery list we tend to forget things and have to go back and forward in the store. We don't seem to remember that we need milk until we're six aisles away from dairy products and looking at dog food. Things don't seem to happen in the order we'd like them to; there's no logical pattern to the way we walk around the grocery store...