Macromedia Flash8 Bible

Troubleshooting problems with a Flash movie can be quite difficult. Depending on the complexity of your movie(s), it can be quite involved. The two main areas where you can experience problems with your movie are as follows: the structure and design of your movie, or your ActionScript code. However, this can be extended to other technologies your movie may use. For example if you use a Web server that relays XML data back and forth, the problem could lie in the connection and processing of data and may have nothing to do with the Flash movie. Similar issues can exist if you're using Flash Remoting or Flash Communication Server applications. We have compiled these troubleshooting checklists to help you solve some problems that may occur during your Flash development.

Good Practices

The following list will help you alleviate the need for troubleshooting your movie and prevent many problems from occurring:

• Planning: Planning can be a tedious task. However, it can also be the start to a very successful project. If you plan your project from start to finish, you can pinpoint potential problem areas before you have even begun.

  Note

  We are not referring to a time schedule, but the processes and methods you use to satisfy the requirements of a project.

• Incremental file saving: A major problem may arise in your movie that can slow production. It may be easier to revert to the last saved version in your movie. This can be an easy task by incrementally saving a new copy of your movie at each milestone.

  Note

  We suggest using the file name_version number naming convention as a useful naming structure. Some examples of this convention are movie_01.fla, movie_02.fla, and so on. A milestone should be considered a significant point in your project — a step closer to completion of your project.

  Tip

  An even better way to keep past copies of your source code and Flash documents is to use versioning software such as CVS or Microsoft SourceSafe. These systems enable you to check the same file in iterations, without the hassle of renaming the file each time you store (or commit) the file to the system.

• Regular testing: While you create your movie, you should start testing early in the development process. Regular and thorough testing can help point out problems that may occur down the track.

  Not only should you test regularly, but you should also test in the target environment. (You can use the testing matrices we discussed earlier in this chapter.)

• Comments: When you write ActionScript code, you should comment each function or block of code. Many problems can arise as a result of simply not remembering what each function or block of code does. Without comments, you might accidentally skim over the exact trouble location because you can't remember what the function does or how it works. Comments should be short and concise, going into detail if necessary.

  Not only should you comment your ActionScript, but you should also comment your frames. Have a layer named "comments" in your movie. On any given keyframe of this layer, place a comment in the Frame Label field of the Property inspector to remind yourself what a particular frame does or is used for.

• Naming conventions: Make sure all aspects of your movie are named properly, including ActionScript. Make sure you've given each function a descriptive name. This should also be applied to variables and objects. Your naming conventions should extend beyond ActionScript; you should name each layer, scene, and symbol descriptively.

• Rest: If you find a lot of simple problems occurring, chances are you are just tired and overworked. A lot of problems arise when you are mentally exhausted. Often the best thing to do is get some sleep and come back refreshed. Typos are a common problem when you get tired. Take regular breaks also — they really do help.

General Troubleshooting Checklist

The following is a list of guidelines that you should follow when you are not too sure where your movie is faulting. Both developers and designers should read these general guidelines; often, simple mistakes cause problems in your structure and ActionScript.

• Locked, hidden, or Guide layers: A common problem occurs when you accidentally lock or hide a layer. It is easy to overlook ActionScript that resides on an object that you can't see, due to the layer being locked or hidden. Also, any object residing in a Guide layer will not be included in the generated .swf file.

  Caution

  ActionScript code on a Guide layer will be exported with your Flash movie. If you're intentionally using a Guide layer to prevent elements on that layer from being exported, make sure you don't have any conflicting ActionScript on any keyframes of the Guide layer.

• Naming conflicts: It is quite easy to give multiple objects the same name. This can occur in ActionScript or in naming frames and objects. A good practice is to make sure that each variable, function, object, and property has a unique name.

• allowScriptAccess: When working with Flash movies in combination with JavaScript or VBScript, the allowScriptAccess attribute of the <embed> and <object> tags in HMTL has to be set to true. Without it, Flash movies cannot communicate with JavaScript. You can learn more about this type of interactivity in Chapter 22, "Integrating Flash Content with Web Pages."

Designer Troubleshooting Checklist

This checklist is a simple guide to problems relating to the structure and layout of your movies.

• Graphics or Movie Clips: Problems occur when you think an object is a Movie Clip but it is really a Graphic symbol. You can't name a Graphic symbol or reference it in ActionScript code.

• Edit mode: It is quite easy to become confused as to which timeline or editing mode you are in. You may think you are editing on the Main Timeline, when in fact you are two timelines deep.

• Action placement: Be sure you haven't confused the type of action you're using on a particular object. There are three types of action modes in Flash 8: Frame, Movie Clip, and Button actions. Often, these are confused and become a problem. For example, you may accidentally add actions to a keyframe when you mean to add them to a Movie Clip instance.

Developer Troubleshooting Guidelines

This is a list of common problems that may occur when you are writing ActionScript. Problems in your project can spread far and wide; these might also be caused by one or more trouble areas that we covered in the general or designer guideline sections. It is to your advantage to read all the troubleshooting areas to maximize your chance of solving problems.

• Object and frame label names: Make sure you have correctly named your objects and frame labels using the Property inspector. This can alleviate many problems, which may be caused by a poor naming structure. Names are case sensitive in Flash Player 7 and higher! As such, make sure you have the name correct, both on the frame or object and in your ActionScript code where you are referencing the frame or object.

• Paths: When referencing objects, frames, or variables, make sure you have the path correct. It can be quite confusing using relative paths such as this and _parent, and this can often be the source of major problems.

  Tip

  You can use the Insert Target Path button in the Actions panel to help target nested Movie Clip instances. See Chapter 19, "Building Timelines and Interactions," for more details.

• Conflicting namespaces: When creating an object or declaring a variable, make sure it isn't the same as a predefined object or variable name in ActionScript. Likewise, make sure you have unique objects and variable names.

• Conflicting frame actions: Many simple problems are caused by conflicting frame actions. You may have a stop(); action on Layer 1 at frame 20 and a play(); action on Layer 2 at frame 20, which would stop your movie from stopping. As such, you should keep your actions on one layer per timeline. For more information on this topic, see the sidebar "Layer Order and Execution Order" in this chapter.

  Layer Order and Execution Order

  The order of your layers determines the order in which your ActionScript is executed. If the layers are not ordered properly, it can cause problems in your ActionScript code. Follow these steps to set up an example to illustrate this problem:

  1. Open Flash 8 and choose File ⇨ New to create a new file.

  2. Choose Insert ⇨ Layer three times so you have a total of three layers in the movie.

  3. Open the Actions panel by choosing Window ⇨ Actions.

  4. Select frame 1 of the top layer and enter this code: var i:Number = 20;.

  5. Select frame 1 of the middle layer and enter this code: var i:Number = 30;.

  6. Select the frame 1 of the bottom layer and enter this code: trace(i);.

  7. Test the movie by choosing Control ⇨ Test Movie. The value of i will be sent to the Output panel and it should be 30.

  8. Drag the topmost layer beneath the second layer, so you have reversed the i declaration order.

  9. Test the movie by choosing Control ⇨ Test Movie. The value of i will be sent to the Output panel and it should now say 20. As you can see, the last declaration of i sticks and the first one is overwritten. This can affect any type of ActionScript object: variables, functions, or objects.

  The layer order specified on the Flash tab of the Publish Settings dialog box also controls the order in which Flash draws the layers over a slow network or modem connection.

• Confining the problem: Make sure the problem exists with the Flash movie. When you work with server-side elements, the problem could be on the server. You may have a problem with the connection or with database information being passed back and forth. Make sure you test your server-side scripts for errors also. Oftentimes, developers will create non-Flash interfaces in HTML to test the functionality of server-side elements to isolate any problems before integrating the same data with a Flash movie.

• Strings or expressions: A common problem is using a string when an expression should be used, and an expression when a string should be used. When you are writing code in the Actions panel, make sure you have quotes when you are writing a string and no quotes when you are referring to an object, function, or variable. For example, trace(test); will try to send the value of test to the Output panel, rather then send the string "test" to the Output panel.