ActionScript - External Source Files

ActionScript is the language used to program Adobe Flash movies. It can be imbedded inside the Flash movie (form), or placed in external *.as files. Most of the help examples work using an external file. However .....

Path vs Name | Sharing Code | Crash | Globals | Including External Source | No Overloaded Functions | Notes


Path vs Name

The help says that the syntax is

That is actually not correct - the "packageName" is actually the.package.path. For example, must be stored in the following file and directory Anything else will cause an error ... this is not in the help files.

Also, note that the public tag is required ... also missing from the help.


Sharing Code - How to specify a classpath

Important - to share code (*.as files) between multiple projects, you need to specify one or more search paths. Set paths for all projects using and paths for just the current project using By default, Flash searches the current directory (shown as a dot) and $(AppConfig)/ActionScript 3.0/Classes, which is at These define the path to the beginning of the projectPath described in the previous section.

In the help, search for Modify the classpath and Set the classpath for ActionScript 3.0 for more information. Similar settings are used for configuring ActionScript 2.


Crash

Most of the examples described in the help files use packages where the main object is created by placing the package's name in the form's Document class property. In every case I've seen, the code is executed via the class constructor.

In every case

In general - this works ... but if you then use F9 to add additional code ... the application crashes.

I have found nothing on this in the help - just a couple of days of trial and error before I gave up.

Note: This is an "either/or" condition ... do NOT use the Document class property and internal code in the same form.


Globals

Each package can be used to define only a single public item - class, constant, variable, function ... - if you want to define global values or functions, each one must be in a separate package (*.as file). The following error message was generated when trying to place 2 global values in the same file. In order to define several global values in a library In this example, mcCommon is the name of the library This is the contents of CRLF_mc.as - it just defines a constant I use. The block comment with the date is just for QC, I find this useful and use it in most of my files.

This is the Flash code I used to test this method ... it works.

You can use as many *.as files as you like, but the code will not be executed until you call the public entry point.

This method is extremely inefficient, using 4 to 30 kilobytes to store only 50 bytes of data really eats up your hard drive. I can't believe that any intelligent person thinks that this is a good idea.

Note: After many frustrating hours, none of this was found in the help files. I finally understood this after reading page 134 of Essential ActionScript 3.0, O'Reilly.


Including External Source

In addition to including classes, you can directly include (read and execute) external source files.

Notice that the import directive points to a project that contains a single public instance.

The include directive actually reads a file into the current source and compiles it there. These files must not include the project directive.

Unfortunately, because ActionScript 3.0 does not provide a conditional include directive (found in all real languages), you can not use this method to include the same information in multiple files.


No Overloaded Functions

There is no way to over load a function - have multiple functions with the same name but different parameter types. To some extent, this is not a big deal since many variables appear to be variants.

However, it creates a problem for me because I want to convert some libraries to ActionScript 3.0.


Notes

I have a copy of Essential ActionScript 3.0, by O'Reilly - 900+ pages $55. While I have found it useful, I do NOT recommend it for experienced programmers. It is extremely wordy and repeats the same concepts several times on the same page. Perhaps this is good for non-programmers ... but I find it VERY frustrating.

On the other hand, it does contain some technical data that Adobe decided to hide from us.


Author: Robert Clemenzi - clemenzi@cpcug.org
URL: http:// cpcug.org / user / clemenzi / technical / Languages / ActionScript / ExternalSourceFiles.html