Common errors

1. Targeting errors

Targeting errors are extremely frequent among beginners and experts alike. These errors can be very hard to spot. A common issue for beginners is the distinction between library name, export identifier and instance name; this leads to confusion and often errors. When you create a symbol, you give it a library name:

You will then see this name in the library. This name is NOT exported in the swf. You will never refer to this name in scripting; it is therefore completely arbitrary.

If you drag an instance of this clip onto the stage, and select it, you will have access to the instance name. You will enter it in the properties panel:

You will refer to the movieclip by its instance name in scripting. It is therefore very important that it consistent with your scripting. Textfields and buttons have instance names as well, and they are just as important.

By right-clicking on a movieclip in the library and selecting Linkage, you will access the clip's linkage properties. By checking "export for Actionscript", you will notice yet another name input, the identifier. You will only use the identifier with attachmovie. Sounds can also use identifiers, and they work in much the same way: they are only used in with the Sound.attachSound and Sound.stop functions.

When a script involving movieclips does not work correctly, a first step is to check that the instance name and the name in the script are one and the same. This brings me to my next important point: Flash MX 2004 is case-sensitive. This means it makes a difference if you use capitals letters or not. So calling gotoAndStop and gotoandstop will NOT give the same result: only the first will work. This is true of built-in functions and of user-created objects.

Flash has a rich but complex hierarchical structure; this means objects (including movieclips) can be nested. This is a great feature of Flash but it can cause headaches: make sure you correctly refer to the path of the objects you are manipulating. If you are not familiar with proper movieclip and object referencing, please refer to Jesse Stratford's Paths to Objects and Variables tutorial.

2. Name clashing

Name clashing is a special, virulent case of targeting error. It happens when two objects are of the same name in a given path. You may have noticed that I sometimes speak interchangeably of movieclips and objects. That's because movieclips ARE Objects. They behave in a peculiar way, yes, in that by modifying their properties their appearance on stage changes, but they are objects.

If you give a movieclip an instance name, and then create variable or object of any type of the same name in the same path, you will 'overwrite' the reference to the movieclip and lose access to it. If you're getting cryptic errors such as a movieclip's _x property being undefined, this may well be the cause.

This applies to not only movieclips but to all actionscript objects. Here's an example of what NOT to do:

function test()
{
        test = "Here's a test";
        return test;
}
trace(test());
trace(test());

If Actionscript 2 exporting is selected, the script simply doesn't compile, as Flash is smart enough to spot the error; in AS1 mode it shows the following output:

Here's a test
undefined

The reason is that inside the test function the function itself is overwritten. Therefore on the second call, Flash can't resolve the function and returns and undefined value.

Another common form of name clashing is having two movieclips by the same name. For example, you place a radio button component on stage and give it an instance name of 'radioBtn'. Then you copy and paste it several times on the stage. When you test your movie, your radio buttons behave erratically: when you roll out of a radio button it disappears, or it doesn't work at all. This is because Flash can't refer to the movieclips correctly because they have the same names.

3. Errors in the function chain

When creating complex movies, you will have several functions that act as event handlers for various objects, as well as generic user-defined functions. Some functionality may not work at all when you test your movie. Before checking for any other error, please, check if the relevant function is actually called. Just place a trace('in'); action at the beginning of the function to see if it is called. If you don't see 'in' in the output panel when you test your movie the function is never called. Most likely this is simply a targeting error; double-check your object and function names to see if they are coherent.

4. Function references and function strings

If after checking your function names, everything looks all right but your movie still does not work, it could be because you are using a function string where a function reference is required, or vice versa. For example:

function showTimer()
{
        trace(getTimer());
}
_root.onEnterFrame = "showTimer";

This looks like it should work, but it does nothing. This is because onX handlers expect function references, not function strings. If you remove the quotes on the last line, the movie will work properly. Most of the time, Flash will want a function reference. There are some notable exceptions, however; for example when using setinterval with an object as the first parameter, the callback parameter is a function string.

This type of imbroglio also happens, though less often, with variables. For example, Object.watch requires a variable string as the first argument and a function reference as the second. Very confusing indeed. Look at the examples in the Actionscript Dictionary for specifics.