The application folder of Flash CS4 Professional includes installation files for two distinct versions of Flash Player. These versions are located in Debug and Release subfolders of the following locations:

These installation files include:

These installation files let you install debug versions of Flash Player for testing locally inside a browser—then to switch back to release versions any time you please. Debug versions are identical to the non-debug-enabled (release) versions, except that the debug versions contain additional code to communicate with Flash CS4. While convenient, because they avoid the delay of a download from http://adobe.com, these files are limited to whatever minor point release they represent. If the Adobe update utility hasn’t yet updated Flash CS4 on your computer, these installation files might not let you test everything you’d like to from within the authoring tool.

The latest installation files are available at http://www.adobe.com/support/flashplayer/downloads.html. Older versions are archived at http://www.adobe.com/go/tn_14266/ for testing purposes. To ensure that installations succeed, Adobe recommends that you uninstall existing ActiveX controls and/or plug-ins before re-installing different versions. This can become tedious, so you may want to consider downloading Flash Switcher, a third party Firefox extension to do the work for you. Flash Switcher was written by Alessandro Crugnola and is freely available on his website for Firefox 3 on Windows, Mac, and Linux:

Figure 2-1. Adding a version of the Flash Player plug-in to the Flash Switcher Firefox extension

In addition to installation files, the Release and Debug folders contain a standalone executable: FlashPlayer.exe on Windows and Flash Player.app on Mac. Flash CS4 uses this executable to create Projectors or view standalone content. When you select Control→Test Movie, for example, the executable inside the Release folder displays your SWF file in the authoring tool. When you select Debug→Debug Movie, the executable inside the Debug folder is used instead.

The parent folder, Players, contains a copy of this executable. This copy is the one used when you launch a local SWF file outside of the authoring tool, for example by double-clicking a SWF file from the desktop. You can control which version is used—debug or release—by copying (not moving!) the desired executable from its respective Debug or Release folder into the Players folder.

Debug versions of Flash Player are capable of logging trace() statement output to a text file. For more information on this topic, see Chapter 11.

Flash CS4 provides a convenient mechanism for ensuring that website visitors have the version of Flash Player they need in order to view your content. It’s a simple configuration under File→Publish Settings→HTML, as seen in Figure 2-2. Select “Detect Flash Version” as shown, and specify the desired version numbers—here, 10, 0, and 2—which indicate the minimum version of Flash Player your content requires. The fourth number, seen in the series 10.0.2.0, identifies the internal build number, which may run a wide range during private Adobe beta testing but is typically 0 for public releases; in any event, the fourth number is irrelevant for ensuring compatibility in this context.

The first number isn’t editable from the HTML tab of this dialog box, and, in any case, needs to be 9 or higher to support ActionScript 3.0. If you choose to publish to older versions of Flash Player, you may change the first number in the version series by selecting this dialog box’s Flash tab, and then changing the Version listbox selection to a previous version of Flash Player. Anything lower than Flash Player 9 will force the Script listbox to change to ActionScript 2.0 or lower.

Figure 2-2. Detecting Flash Player version in HTML publish settings

Employing version detection changes the way the authoring tool writes the HTML it uses to embed a published SWF file. For that reason, it’s useful to understand how the HTML is written by default. At the time this book was being written (before the public release of Flash CS4), the default HTML template—that is, no Flash Player version detection—generated an HTML document with inline JavaScript (not an external .js file). This JavaScript embedded the SWF file dynamically, a feature that was necessary for the Internet Explorer browser between February of 2006 and April of 2008. Without such JavaScript, Internet Explorer users had to signify their intention to interact with Active Content—that is, Flash, QuickTime, Java applets, and so on—by first clicking the Active Content in their browser.

It may be that the commercial release of Flash CS4 no longer includes JavaScript with its default HTML template, in which case the parameters in the HTML tab of the Publish Settings dialog box will only affect the HTML itself.

The configuration parameters shown in Figure 2-2 affect the HTML <param> tags that appear as children of the <object> tag used by Internet Explorer. These, in turn, correspond almost point for point with attributes of the companion <embed> tag used by Mozilla compatible browsers.

One of these settings—codebase, which only appears in the HTML, not the dialog box—is used only by Internet Explorer. If a user has an older version of Flash Player installed, Internet Explorer compares the version number of the installed ActiveX control against the codebase attribute to determine if an upgrade is merited, in which case the user is prompted as shown in Figure 2-3. If Flash Player is absent altogether, the same installation prompt occurs. For an example of the former case, consider that, as of the time this chapter was written, the default codebase value was 10.0.2.0. In Flash CS3, this value was 9.0.0.0, a “perfect” initial release number that has no real-life Flash Player counterpart. If you needed to use, say, the Event.ADDED_TO_STAGE event constant introduced in minor point release 9.0.28.0, then you could change the codebase value by hand after Flash CS3 generated the HTML. You can do the same with Flash CS4, if a higher minor point release is required. Just make sure, if JavaScript is included, to update any mention of codebase both in the JavaScript and the HTML.

Figure 2-3. Internet Explorer prompting an installation of the Flash Player ActiveX control

In a sense, this is a rudimentary approximation of version detection, but it’s essentially flawed. Why? From an aesthetic and usability standpoint, you want to avoid an interruption of the user’s experience. In addition, Mozilla compatible browsers ignore codebase in favor of the roughly analogous pluginspage attribute to determine whether to present a similar prompt. The difference is that pluginspage makes no distinction among Flash Player versions: Mozilla browsers always install the latest version, even if you don’t need the latest.

By and large, encouraging the latest version of Flash Player seems to make sense. Generally speaking, installation is a relatively trivial affair, even if it is an interruption. If your website visitor has the latest version installed, it doesn’t matter if your content requires only, say, 9.0.16.0. Modern browsers make installation or upgrades practically effortless for most home users, but not every user scenario occurs at home.

In most corporate, government, and educational settings (think libraries!), individual users are rarely given administrative rights to the computers they use. These content viewers can’t agree to an upgrade when prompted by the browser—in fact, the prompt may not even happen—so at best, such viewers may be faced with an upgrade proposition they can’t act on and at worst, a webpage with obviously missing content. By leaving the codebase attribute at the lowest required value, you might steer clear of a few unnecessary interruptions for Internet Explorer users, but your best bet is version detection.

When “Detect Flash Version” is selected on in the HTML tab of the Publish Settings dialog box, the JavaScript code is slightly altered, which comes as no surprise. (Remember, if the HTML templates change in the commercial release of Flash CS4, then it won’t be that the JavaScript is altered, but rather, that it is introduced into the publish process.)

The detection-specific JavaScript provides a mechanism more reliable than the codebase or pluginspage HTML tag attributes. With detection engaged, the user’s installed Flash Player can be checked against major, minor, and revision values, as specified below the “Detect Flash Version” checkbox in the dialog box.

In addition, a notable change happens to the HTML. In this case, content inside the <noscript> tag no longer contains the backup <object> and <embed> tags. Instead, you’re expected to provide your own alternate content. This might be an explanatory line of text, as suggested by the generated markup, but could just as easily be an image or any other valid HTML, including, if you want to risk it, an alternate SWF file published for an older version of Flash Player.

<noscript>
    // Provide alternate content for browsers that do not
        support scripting
    // or for those that have scripting disabled.
    Alternate HTML content should be placed here. This content
        requires the Adobe Flash Player.
    <a href="http://www.macromedia.com/go/getflash/">Get Flash</a>
</noscript>

This markup is mirrored in an else clause just a few lines prior:

} else {  // flash is too old or we can't detect the plugin
        var alternateContent = 'Alternate HTML content should ¬
             be placed here.'
            + 'This content requires the Adobe Flash Player.'
            + '<a href=http://www.macromedia.com/go/getflash/>
                Get Flash</a>';
        document.write(alternateContent);  // insert non-flash content
    }

This code is what gets displayed if the user has JavaScript enabled, but not the minimum required version of Flash Player. Here too, the HTML written out by JavaScript can be replaced with more appropriate or targeted content of your own choosing. In this way, you can provide an experience of progressive enhancement, in which essential content is presented to the user in all cases, and augmented for the user who has Flash Player installed.

Although you can reproduce the functionality of the following class with timeline code, doing so would largely defeat the purpose of using an external code editor. This code defines a custom DragParrot class that, when configured as the document class of a specific FLA file, results in a pre-drawn parrot in a circle that you can drag only when a checkbox is selected (Figure 2-4). The ActionScript is stored in an external text file, DragParrot.as, saved in the same folder as its companion, DragParrotExample.fla. You can use the exact same code in each of the script editors discussed in the following sections.

Figure 2-4. The DragParrot class in action

It’s important to keep in mind that some of the assets required by DragParrot are stored in a separate FLA file, included with the samples that accompany this book. These assets are configured to be exported for ActionScript in the Linkage area of the Symbol Properties dialog box accessible from the Library panel. They don’t appear anywhere on the FLA file’s stage. Prior to ActionScript 3.0, these assets would have been assigned a linkage identifier, but the attaching mechanism has changed in the new language. Attachable assets are now assigned a linkage class, which defines the asset in terms of an appropriate base class, such as MovieClip or Sprite. This linkage class can be composed of custom ActionScript, but it doesn’t have to be. In fact, by default, the Flash authoring tool automatically writes this class for you, in which case the class isn’t saved as a separate AS file, but included virtually into the SWF file. If you’re coding in an external script editor and compiling in Flash CS4, you can trust that linkage classes are “magically” available at compile time.

The DragParrot class, shown in the following code, begins by importing a set of external classes it needs to perform its tasks. The first of these, Parrot, obviously stands out as a custom class. This is the linkage class handled by the Flash authoring tool. As it happens, CheckBox is also a library asset (an instance of the CheckBox component) and must be present in the library. After class properties are declared, the constructor function, DragParrot(), calls on a handful of descriptively named methods.

package {

    import Parrot;
    import fl.controls.CheckBox;
    import flash.display.Sprite;
    import flash.events.MouseEvent;

    public class DragParrot extends Sprite {

        private var _ball:Sprite;
        private var _parrot:Sprite;
        private var _checkbox:CheckBox;

        public function DragParrot() {
            drawBall();
            addParrot();
            makeCheckBox();
            assignEventHandlers();
        }

These methods are fairly basic. The first, drawBall(), calls on a special set of functionality from the Graphics class, collectively known as the Drawing API, to draw a light blue circle into a Sprite instance, and then adds this object to the display list, so that it can be seen.

        private function drawBall():void {
            _ball = new Sprite();
            _ball.graphics.lineStyle();
            _ball.graphics.beginFill(0xB9D5FF);
            _ball.graphics.drawCircle(0, 0, 60);
            _ball.graphics.endFill();
            _ball.x = stage.stageWidth / 2;
            _ball.y = stage.stageHeight / 2;
            _ball.buttonMode = true;
            addChild(_ball);
        }

The addParrot() method attaches pre-drawn artwork from the companion FLA file’s library by instantiating the linkage class Parrot. This object is added to the display list of _ball (created in the previous method), which makes the artwork a child of that object.

        private function addParrot():void {
            _parrot = new Parrot();
            _ball.addChild(_parrot);
            _parrot.x = _parrot.width / −2;
            _parrot.y = _parrot.height / 2 − ¬
                _ball.height / 2;
        }

The makeCheckBox() method attaches a component from the companion FLA file’s library by instantiating the linkage class CheckBox. The checkbox is positioned in the lower left corner of the stage, given a label “Allow drag”, and then added to the display list.

    private function makeCheckBox():void {
            _checkbox = new CheckBox();
            _checkbox.x = 10;
            _checkbox.y = stage.stageHeight - 30;
            _checkbox.label = "Allow drag";
            _checkbox.selected = true;
            addChild(_checkbox);
        }

Finally, assignEventHandlers() associates _ball with two event handler methods. Thanks to an if statement, the dragParrot() handler responds only when the checkbox is turned on.

private function assignEventHandlers():void {
            _ball.addEventListener(MouseEvent.MOUSE_DOWN, ¬
                dragParrot);
            _ball.addEventListener(MouseEvent.MOUSE_UP, ¬
                dropParrot);
        }
        private function dragParrot(evt:MouseEvent):void {
            if (_checkbox.selected) {
                _ball.startDrag();
            }
        }
        private function dropParrot(evt:MouseEvent):void {
            _ball.stopDrag();
        }
    }
}

This class could have been written in a Script window of the Flash authoring tool or in any simple text editor. The remaining sections touch on four popular alternative ActionScript editors. Bear in mind, none of these applications exclude the use of one another. If you like, sample each one to get a feel for their nuances. You might just decide you like them all!

As mentioned earlier in this chapter, Flex Builder 3 is Adobe’s answer to traditional programmers interested in developing for the Flash Platform. To be sure, Flex Builder is hardly just a script editor. Its full benefit becomes clear when you use it to leverage the Flex framework, which includes dozens of user interface (UI) components and data classes not available in the Flash authoring tool (though freely available with the Flex SDK). These elements are geared toward the development of Rich Internet Applications (RIAs), which are Flex’s specific focus. In addition to ActionScript 3.0, Flex Builder can create and edit MXML, an XML-based markup language used to declaratively lay out interface elements and, in conjunction with ActionScript 3.0, implement business logic and facilitate remote procedure calls (RPCs). Built on the Eclipse platform, Flex Builder benefits from hundreds of third-party plug-ins, which extend basic functionality across a wide range of topics. Many of these plug-ins are free (see http://www.eclipseplugincentral.com/) and work with both the stand alone version of Flex Builder and the version that is, itself, a plug-in for Eclipse.

Muscle notwithstanding, Flex Builder 3 is perfectly capable of creating and editing straightforward ActionScript 3.0 classes. Although the Flash authoring tool’s Actions panel and Script windows get the job done, the powerful editing capabilities of Flex Builder raise the bar considerably.

Figure 2-10. Errors are displayed and summarized as they occur

Figure 2-11. Compiling in Flex Builder succeeds when code doesn’t rely on FLA file library assets

Figure 2-12. Tooltips display data types

SE|PY is a free ActionScript editor for Windows and Mac written in Python by Alessandro Crugnola. It was originally developed for ActionScript 2.0, yet continues to be very popular and works quite well with ActionScript 3.0 and even JavaScript. Information on SE|PY and downloads are available at http://www.sephiroth.it/python/sepy.php. Helpful tips are occasionally posted at http://www.sepy.it/. If you like what you see, consider making a PayPal donation.

Compared with Flex Builder 3, SE|PY (Figure 2-13) is a svelte application, and purposefully so. It offers a quick-loading interface with a Swiss Army knife assortment of practical minitools. When working with ActionScript 3.0, you’ll use SE|PY to write your ActionScript, and then switch over to Flash to compile. Here are a handful of the goodies that await you.

Figure 2-13. The slender but powerful SE|PY ActionScript editor

A number of tabs run down SE|PY interface’s left edge. The tab selected in Figure 2-14, Members, is similar to the functionality of Flex Builder’s Outline view. Class members are indicated by icons and, when double-clicked, highlight the corresponding section of code. In this implementation, members are displayed alphabetically, regardless of their order in the ActionScript, which eases navigation. The input field at the top filters members as you type (Figure 2-14), so you can easily locate methods in complex class files. Notice that the letters “dr” have highlighted methods whose names start with those characters. Adding “a” (“dra”) omits dropParrot() from the list, and so on. To clear filtering, delete the contents of the input field.

Figure 2-14. The Members tab supports filtering

The Snippets tab gives you a handy way to reduce the tedium of typing common blocks of code, fittingly known as snippets. The green cogwheel icon (Figure 2-15) lets you categorize snippets by folder on your hard drive. You might create folders for ActionScript 3.0, 2.0, JavaScript, and XML.

Figure 2-15. Snippets make it easier to type common blocks of code

The next few steps walk you through the creation of a SE|PY snippet.

Figure 2-16. Using a more sophisticated snippet

You have nearly a dozen additional tabs and tools, including:

FlashDevelop is a compelling open source script editor for Windows designed for ActionScript 3.0 and 2.0 development. Built on the Microsoft .NET Framework, this application functions comfortably as a standalone IDE or in conjunction the Flash authoring tool. FlashDevelop is produced by Mika Palmu, Philippe Elsass, Nick Farina, and contributors. Information and downloads are available at http://www.flashdevelop.org/ or http://osflash.org/flashdevelop/.

Figure 2-17. The FlashDevelop Start Page

Figure 2-18. Configuring the Flex SDK location

Figure 2-19. Creating an ActionScript 3.0 project

Figure 2-20. Choosing the project’s main class file

FlashDevelop supports a remarkable number of the tools featured in the other script editors discussed in this chapter. Naturally, individual nuances differ from application to application, but FlashDevelop includes its own version of the following:

PrimalScript, by SAPIEN Technologies, is a powerhouse script editor for Windows. This application is conversant in ActionScript 2.0 and also 3.0—provided you help it out, which is discussed in the following steps. PrimalScript gives you much of the expected code coloring, autoformatting, and code completion seen in the Flash authoring tool and Flex Builder. If you want to explore other languages, you’re in luck, because PrimalScript supports over 40 more, including HTML, CSS, JavaScript, Java, C#, PHP, Python, Ruby, Perl, Tcl, and the list goes on. Application information and downloads are available at http://www.primalscript.com/, with three editions to choose from: Standard, Professional, and Enterprise. Fully functioning 45-day trials are available for all editions.

Longtime users of PrimalScript may notice that the application manages just fine in ActionScript 2.0 but offers minimal support in ActionScript 3.0 out the box. To work around this limitation, you have to give the application access to a set of specially formatted class definitions for ActionScript 3.0 called intrinsic classes. Fortunately, FlashDevelop (discussed in the previous section) includes an unofficial set of intrinsics, which you can re-use with PrimalScript:

Figure 2-23. Providing ActionScript 3.0 intrinsic classes to PrimalScript

Like the other scripting IDEs mentioned in this chapter, PrimalScript features numerous additional amenities, all of which can boost your workflow productivity: