Focus on Distinction

John laPlante's blog. The title comes from the idea that there is often some critical detail that makes all the difference in a design, a movie, an event, etc. I am espeically interested in usability and design.

Monday, January 19, 2009

The pain of Flash CS3 & ActionScript 3

I recently began using ActionScript 3 for Flash work. I'm surprised that there are so many gotchas because of the changes to the language and the environment. I think there is a close parallel between the changes that Adobe made and the changes in XHTML. Both require much more stringent adherence to official practice and syntax. For example, XHTML requires all tags be closed. I've heard arguments in favor of this such as that the browser doesn't have to do so much work to detect and correct malformed HTML. But, this puts the onus on the author to get things right. I'm attracted to the idea of having the computer do the my work. The parallel in AS3 is that the author has to write object oriented code rather than writing simple snippets. For really simple things, this is a major pain. For big jobs, it's not so bad but still, lots of learning.

An example of unnecessary complexity is in combining manual use of the library and the document class. It's common for Flash authors to drag a library item onto the stage and then begin scripting it in a frame script. The instance name is a easy way to reference items. But if you use a document class, then referencing a item on the stage is easy to screw up. The class has to have a few things
  1. Uncheck 'automatically declare stage instances' from a dialog within a dialog titled 'ActionScript 3.0 Settings'
  2. Add a variable with the name of the stage item. The stage item has to have the same instance name . E.g., public var img1:MovieClip;
  3. The previous line requires importing a reference to the MovieClip class. E.g., import flash.display.MovieClip;
I wrestled with this for a while and researched it until I found a workable solution. Item 1 is entirely unintuitive. If you don't do this, Flash produces a less than helpful error:
1151: A conflict exists with definition img1 in namespace internal.
This means that the variable can't be defined (a.k.a., declared) twice. The Flash compiler tends to want to auto define/declare things if the user doesn't and in this case, with that checkbox checked, Flash went ahead and declared the variable. Other cases where Flash auto creates is the Document class and a default class when the user chooses Export for ActionScript on a MovieClip symbol. It would be nice if Flash was smart enough to look in the Document class to see if the variable has been defined and then avoid doing it again.

If you don't add a variable to the class (item 2), then you get the following error:
1119: Access of possibly undefined property visible through a reference with static type Class.
This means that you are trying to refer to a variable in your class that isn't defined. The need to define/declare MovieClips as variables in the class has been around since AS2. But even then it was annoying that the Flash compiler can't look for symbol instance names.

If you don't give the stage item an instance name (item 2) then the movie compiles but when you invoke any code that references the stage item, you get this error and a stack trace.
TypeError: Error #1009: Cannot access a property or method of a null object reference.
The runtime can't find the MovieClip on the stage because it doesn't have a name. It would be nice if they were to mention the class property name at least. This is the worst situation because it is so hard to figure out. It is easy to forget to name a item on the stage.

Item 3 demonstrates how ActionScript 3 is much stricter than ActionScript 2. If you leave the import statement out of the class, you get the following errors:
1017: The definition of base class MovieClip was not found. 5000: The class 'com.efi.LessScreen.LessScreensClazz' must subclass 'flash.display.MovieClip' since it is linked to a library symbol of that type.
This is std stuff for languages like Java but it still is overhead that makes it harder to work with the language. If you use a tool like FlashDevelop or Flex Builder, it generally auto-inserts import statements.

It turns out that it is generally easier to leave the stage empty and add items through code. But, this defeats some of the power of the library. Maybe it is time to switch to Flex where it seems the code editor and the visual editor for components are more closely tied.







Some of this is discussed on the blog Dreams And Creations.
Moock also has some material on this: Moock Lectures

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home