The Best Structure for your Flash Site - Page 7

And now, the last page! You are almost done.

nCounter += 1;

We increment nCounter by 1 for each button that's generated.

image_mcl.addListener(mclListener);

The addListener method attached to our MovieClipLoader object allows it to receive notification when our image is fully loaded.

The last bit of code is our button click event handler.

function buttonClick():Void {

trace( this.linkURL );

}

This function executes when a button has been pressed. We run a trace on the button's LinkURL property, which we set earlier. If you CTRL + ENTER to pop up the Output panel, then proceed to click some buttons, you should see the associated SWF file displayed in the Output panel.

This is as far as we'll go in this article. If we were to continue, the next step would be to load the SWF file using another MovieClipLoader, just as we did earlier for the image files. However, we've now done enough to get the point. What is the point? Well, let's review.

The Big Picture
We've achieved a lot in this article. We've learned how to import XML into Flash, then parse it and store it in arrays. We learned how to import CSS and assign it to text fields to apply formatting. We also have learned how to use the new filter feature in Flash 8 to apply a drop shadow effect. All this is good, but it's not the main point.

What I want you to take away from this article is the way in which we structured our Flash site. Everything that makes up our Flash site resides outside Flash: our external XML file holds the text that's used for the buttons, the image that's used for the buttons, and the link reference for the buttons. Our external CSS file holds formatting information for the buttons.

Keeping everything outside Flash allows our site to be completely dynamic -- we can make changes at any time and not ever have to touch our Flash file. As a bonus, it also keeps our SWF file extremely small and fast loading.

Also, we were in complete control of the Flash playhead the entire time. We moved the Flash playhead to the next frame on our own terms, not Flash's, which can help to avoid a lot of frustration. Many errors are made in Flash because developers allow the playhead to run wild. We never allowed that to happen; we systematically controlled the playhead. Frame 1 set global variables, then we stopped at frame 2, where we loaded in XML data. Once complete, we stopped at frame 3 and loaded CSS data, and on completion, we stop at frame 4 and build our application.

I hope the principles presented in this article will allow you to better structure your next Flash site. If you have any questions, please post on the forums at http://www.kirupa.com/forum

About Mark
Mark runs Search-This.com, a resource site for Internet marketing and web development. He can also be found at his blog, What a Savage.

Mark Angeletti

1 | 2 | 3 | 4 | 5 | 6 | 7