Storing Scripts

[ LiB ]

Often, I'm sad to say, when I think to use an old script, I usually hunt it down in an old project's source file. This works fine, but it's not exactly ideal. There are many ways to store your favorite scripts so that they're available to you when you need them. This section shows you how to include external ActionScript (AS; extension .as) text when you publish your movie and how to grab your own homemade code snippets from the Behaviors panel.

AS Text Files

Flash supports a feature called #include , which enables you to store your scripts in an external text file. The way it works is that in lieu of writing scripts right inside the Actions panel, you can instead point to an external file. For example, I can put the following script in the first frame of my movie:

 #include "somefile.as" 

Then, when you publish or test the movie, the contents of the file somefile.as is effectively copied into the SWF.

Note

No Semicolon

Notice that lines of code using #include do not include a semicolon at the end.

Not much more to it. Realize that this is done at publish time (not runtime). So if you make a change to the AS file, you must republish all movies that use it.

On the surface, storing your scripts outside Flash may seem like a big pain. It may be worth the hassle, but there are ways to make it not such a hassle. First, the advantage is that you can easily use the same script file in multiple movies or projects. This is much more logical than my technique of copying scripts from old files. You can build a library of AS fileseach one with a different purpose. By the way, AS files can also #include other AS files. So you might have a few generi-cutility AS files, but one applied script that uses #include to use several of the utilities. Finally, the #include call can use relative references such as #include "../filename.as" , where filename.as is up one folder from where the Flash movie resides. In this way, you can point to a common library of AS files.

The fact that AS files are just plain-text files might seem to suggest you need to use a plain-text editor to produce them (which you can). However, you have many better alternatives. Flash MX Professional 2004 supports direct editing of AS files, meaning you can use all the code hinting and stay in the Flash environment with the Help panel and so on. In addition, Dreamweaver MX 2004 enables you to edit AS files and gain code-completion help inline. Finally, there are a host of third-party text editors for which other developers have written syntax coloring, code hints, and code-completion support files. So, although maintaining both the FLA and the AS files takes a moderate effort, it's really not too bad. The hardest thing I find is that I have to remember to save the AS files before I test my movie (or the latest saved version is used instead).

Before moving on to homemade behaviors, let me point out there's a new option confusingly similar to #include; it's called import . You'll see it in the section "Basic Class Files in AS2" later, but just realize the two differ .

Homemade Behaviors

Building a library of utility AS files makes perfect sense. When you have code that's generic enough to externalize, it can keep your FLA files very simple. The idea of such a library is that you (or someone else) wrote the code once, made it accessible through a few methods and functions, but you never really need to go in an edit those AS files because they're complete. Sometimes your needs aren't that orderlymaybe you find yourself frequently typing the same basic code but with significant modifications each time. For such situations, there are behaviors.

Behaviors just paste a snippet of code into your Flash movie. This is similar to how a word processor can run a simple macro. If you've explored the behaviors that came with Flash, you probably found that some are slightly more involved because they let you set a few options to modify certain parameters. But at their core , they just paste a block of code into your scripts. In addition, if you don't mess with the code pasted in, you'll be able to use the Behaviors panel to remove entire blocks of added scripts without breaking the rest of your code. In any event, it's easy to write your own behaviors, and doing so can prove useful for blocks of code you find yourself using a lot.

Here's a great example of code that I find myself typing all the time:

 for(var i in obj){ trace(i+":"+obj[i]); } 

Let's turn that into a behavior. Without documenting the entire XML format, let me just show you how easy it is by example. Listing 13.1 shows the content of a file I saved as Phillips_object_trace.xml inside Flash's Behaviors folder (then restarted Flash):

Listing 13.1. Simple Behavior

 <?xml version="1.0"?> <flash_behavior version="1.0"> <behavior_definition dialogID="my_id-dialog" category="Phillips" name ="Phillip's object trace script"> <actionscript> <![CDATA[ //BEGIN for(var i in obj){ trace(i+":"+obj[i]); } //END ]]> </actionscript></behavior_definition></flash_behavior> 

You can test it out. It simply pastes the text in the CDATA portion of the XML file. In use, I might paste this, and then replace obj with a name of an objectfor instance, _root to see all the clip's in the main timeline.

In the behavior example in Listing 13.1, I didn't define a dialog box; it just pasted the same code no matter what. You can make custom dialog boxes with real live buttons , text entry fields, list boxes, sliders, and more. The example in Listing 13.2 prompts the author for an object name; then that name will be used (in place of obj above). Here's the code for a file named Phillips_object_trace_advanced.xml.

Listing 13.2. Advanced Behavior

 <?xml version="1.0"?> <flash_behavior version="1.0"> <behavior_definition dialogID="my_id-dialog" category="Phillips" name="Phillip's object trace script advanced"> <properties> <property id="loopObj"/> </properties> <dialog id="my_id-dialog" title="Object Trace" buttons="accept, cancel"> <hbox> <label literal="false" value="Enter Object Name."/> <textbox id="loopObj" tabindex="1" required="true"/> </hbox> </dialog> <actionscript> <![CDATA[ //BEGIN for(var i in $loopObj$){ trace(i+":"+$loopObj$[i]); } //END ]]> </actionscript></behavior_definition></flash_behavior> 

Notice there's an entire dialog section to the XML where you lay out the elements to the dialog. Basically, the dialog makes the user set a property (think variable) named loopObj . Then, notice each instance of that property is surrounded by dollar ( $ ) signs indicating the value for that variable should be used rather than the string "loopObj" .

For a feature that I thought was pretty cheesy at first look, behaviors may become the big cheese. Oh, and to call this an "advanced" example is a bit of a stretch, because when you study the documentation for these XML files (called XML to UI), you'll see there's a ton more you can do.

Beyond Flash

The way Flash turns XML into user-interface dialog boxes is through an implementation they call XML to UI based on a standard called XUL ("zool"). Luckily, the time you invest learning it for behaviors comes in handy when building commands (which are covered next ). Commands' only similarity to behaviors is they both use a dialog box for user input. Commands also have the power to run still another language called JavaScript Flash (JSFL), which can effectively run Flash on autopilot (making changes to your document, for example).

If it feels like your head is about to explode, don't worry. First off, I'm only going to give you an overview and a few tips to get started with JSFL. Second, the good news with most of this stuff is the community of developers is already building tools to share. A great place to start after reading the next section is www.actionscript.nl.

[ LiB ]