Man flash is weird. Actually, Flash and Action Script are bizarre. You can stick Action Script almost anywhere, but when the heck does it get executed? And if it's so flexible why does EVERY BOOK tell you to stick an include in frame 1 and NO WHERE ELSE? Stupid thing…

But… it really is a trully platform independent development system. So much to learn…

Okay, Action Script behaves differently than a normal programming language. It is not about the linear execution of a single file that pulls in other files, it is about attaching snippets of code to objects to give them behaviors. It is JavaScript in many ways and was based upon the same standards.

The Timeline of the Movie clip is like “module” scope. When a variable or function is defined at the timeline level it is available to any frame in the timeline. But here's the weird thing. How local variables are created. In a function, if you use the term var a variable is local only to that function. Otherwise, a variable is created or access in timeline (module) scope.

For example:

var timeLineVar = 0; // available anywhere in the timeline.
function foo() 
{
  var myLocal = 1;  // this is available only inside this function.
  myTimeLine = 2;   // this is now available anywhere in the timeline.
}

Coded is executed Synchronously and ASynchronously (or event driven). This information is copied from ActionScript for Flash MX: The Definitive Guide, 2nd Edition published by O'Reilly.

As a movie plays, the timeline's playhead travels from frame to frame. Each time the playhead enters a new frame, the interpreter executes any code attached to that frame. After the code on a frame has been executed, the screen display is updated and sounds are played. Then, the playhead proceeds to the next frame.

For example, when we place code directly on frame 1 of a movie, that code executes before the content in frame 1 is displayed. If we place another block of code on a keyframe at frame 5 of the same movie, frames 1 through 4 will be displayed, then the code on frame 5 will be executed, then frame 5 will be displayed. The code executed on frames 1 and 5 is said to be executed synchronously because it happens in a linear, predictable fashion.

All code attached to the frames of a movie is executed synchronously. Even if some frames are played out of order due to a gotoAndPlay( ) or gotoAndStop( ) command, the code on each frame is executed in a predictable sequence, synchronized with the movement of the playhead.

Some code does not execute in a predetermined sequence. Instead, it executes when the ActionScript interpreter notices that an event has occurred. Many events involve a user action, such as clicking the mouse, resizing the movie, or pressing a key. Other events happen without user intervention, such as a sound completing or an XML document loading. Just as the playhead entering a new frame executes synchronous code attached to the frame, events can cause event-based code to execute. Event-based code (code that executes in response to an event) is said to be executed asynchronously because the triggering of events can occur at arbitrary times.

Synchronous programming requires us to dictate, in advance, the timing of our code's execution. Asynchronous programming, on the other hand, gives us the ability to react dynamically to events as they occur. Asynchronous code execution is critical to ActionScript and interactivity.

Not every event triggers the execution of code or affects a movie. For example, a user can generate dozens of events by clicking repeatedly on a button, but those clicks may be ignored. Why? Because, on their own, events can't cause code to execute—we must write code to react to events explicitly. To instruct the interpreter to execute some code in response to an event, we create either an event handler or an event listener that describes the action to take when the specified event occurs.

Due to its unusual evolution, ActionScript has four different ways of handling events:

• Event handler properties

• Event listeners

• Button event handlers with the syntax:

      on (eventName) {
        statements
      }

• Movie clip event handlers with the syntax:

      onClipEvent (eventName) {
        statements
      }

Okay, I'm trying to make a simple framework. There are still a lot of things that confuse me, but here's my approach so far.

1. Create a layer for components
2. Create a layer for actions
3. Create a layer for the label? (I did this, don't know why). Insert a Key frame every 10 frames for each “page”

I insert ActionScript in each “page” frame on it's Actions layer. The AS is usually an #include for a .as file that contains the code I want to run. So a vertical slice becomes the page or form I'm working on and code gets redirected between the pages.

I have a simple flash app with a mainMenu, a “firstForm” and a menuForm - where I instantiated a menuBar. I still don't fully understand the object architecture, because it looks like when you “goback” to a form it's code is not run again…

okay, so here's a little thing that I learned. At first, I tried to set the event handler in the frame that contained a UI page. That kinda worked, but when I left that frame, AS and Flash acted like the object and the code didn't exist.

For example, I put a button component, on frame 10 and in frame 10's action script, I attached a function to the onRlelease() handler. At frame 20 (another UI screen) the app acted like the the code didn't exist. I had to reinstall the event handler.

However, when I attached the event handler on() to the button itself, the action script worked in ALL frames where the button appeared.

I don't pretend to fully understand this behavior. BUT it's another way to do things.

1. Put common UI elements in their own layer.
2. Attach Action script directly to the objects in that layer, so they execute regardless of what the current frame is.

I'm not aware of any other side effects.