ActionScript 3 Tip of the Day

[senocular]

Originally Posted by romkedehaan

I am getting this error:

Error #1006: invalidate is not a function.

This is frustrating because there are so many new things going on. Everytime I write a block of code I get some silly error. Can someone help?

Be sure to use invalidate off of stage

stage.invalidate()

[nshen121]

in #365

if I load content without check the policy file ,then what will happen?

[senocular]

Originally Posted by nshen121

in #365

if I load content without check the policy file ,then what will happen?

If its on the same server as the SWF, nothing (unusual, that is - the content loads as expected). Content on the same server/domain as the SWF file doesn't need a policy file. Content from different domains do require a policy file, at least if you want data from that content. This means images and sounds may load fine without the file, but text files (XML) and getting bitmapData from images or id3 information from songs wont work unless that policy file is on that domain and loaded by the Flash player signalling that its allowed.

[nshen121]

thanks very much, if I load content from different domains, and I don't set the checkPolicyFile property to true ,that will nothing happens? no Error would be thrown ?

[senocular]

If you're illegally accessing data, a security error will (should) be thrown

[Pattt]

I'm using an (root) array in a code, inside an mc.
Then I get:

1119: Access of possibly undefined property cells through a reference with static type flash.display:DisplayObject.

What's wrong?

[senocular]

Originally Posted by Pattt

I'm using an (root) array in a code, inside an mc.
Then I get:

1119: Access of possibly undefined property cells through a reference with static type flash.display:DisplayObject.

What's wrong?

Looks related to:
http://www.kirupa.com/forum/showpost...&postcount=363

[Pattt]

Originally Posted by senocular

Looks related to:
http://www.kirupa.com/forum/showpost...&postcount=363

Don't know. I'm using:

for (var i=0; i<root.cells.length; i++) {
 }

and in the root:

var cells = [0,0];

Why can't I just use root/_root?

[senocular]

root is typed as DisplayObject. The DisplayObject definition does not contain a cells property so you are getting an error. Instead, recast root to something that will allow you to refernce cells; either MovieClip (which is dynamic) or the document class itself

[Rezmason]

[senocular]

I've added a link to my latest tutorial (still in progress) to the first post.

Getting Started with ActionScript 3.0 in Adobe Flash CS3
http://www.senocular.com/flash/tutor...3withflashcs3/

I will add more tips either tonight or tomorrow.

[senocular]

IEventDispatcher is an interface in ActionScript 3 used to describe objects that have the necessary methods to handle events. Normally this means objects whose class extends EventDispatcher. EventDispatcher, however, can also be used with composition (having an instance defined within the class instead of inheriting from the class to gain the same functionality). If for some reason a custom class needs to be able to handle events but can't extend EventDispatcher, composition will be used. In doing that, it will lose type information with EventDispatcher. For that reason, it, like EventDispatcher, should implement the IEventDispatcher interface.

What this means is that any instance that dispatches and can be used with addEventListener (etc.) for events should at least have an association with the interface type IEventDispatcher. For that reason you should type variables that you would type as EventDispatcher with IEventDispatcher instead. Using EventDispatcher would limit that variable to only object instances whose class inherits from EventDispatcher rather than those that obtain its functionality through composition.

var myDispatcher:IEventDispatcher;

[senocular]

In ActionScript 2, movie clips had a very close association with the timeline in Flash. Once they were created within a timeline, that would be the only timeline in which they could exist until eventually removed, either by the timeline itself (based on frame information) or via ActionScript using removeMovieClip().

References to movie clips in AS2 were also soft references which used a target path to make a connection with a movie clip instance within its parent timeline. If a movie clip was removed from a timeline or non existant at the time a variable referencing the movie clip was accessed, the variable would return no value because to access the variable it uses the target path of the movie clip to obtain a reference. With that target path no longer valid, the variable that would otherwise reference a movie clip instead references nothing (yet the variable will still be considered of the type movie clip). Look at the following example:

// ActionScript 2
var mcRef:MovieClip;
trace(mcRef); // undefined
trace(typeof mcRef); // undefined

mcRef = attachMovie("mySymbol", "mySymbol", 1);
trace(mcRef); // _level0.mySymbol
trace(typeof mcRef); // movieclip

mcRef.removeMovieClip();
trace(mcRef); // [results in an empty trace]
trace(typeof mcRef); // movieclip

attachMovie("mySymbol", "mySymbol", 2);
trace(mcRef); // _level0.mySymbol
trace(typeof mcRef); // movieclip 
 

Even when the movie clip is removed from the screen, the mcRef variable which referenced it continued to reference a "movieclip" even though there was nothing to reference and the movie clip had been effectively destroyed in Flash. When a new movie clip is created in a different depth with the same instance name (hense the same target path) as the original, mcRef then points to that new movie clip as it has found a valid instance within the path it uses to lookup its respective movie clip value.

ActionScript 3 is less cryptic. Display objects are not so dependant on their timeline as before able to move from any timeline to another using addChild, removeChild, and similar methods. They are now also now created like all other objects using the new keyword (as opposed to attachMovie). And with this, variables that reference display object instances work the same way as with other instances meaning if you want to get rid of a display object instance in memory, you need to make sure there are no references to it.

What does this mean for a removeMovieClip replacement in AS3?

For one, you can remove a MovieClip instance (or other display object) from the screen quite easily using removeChild. If you are in the scope of the instance itself, you would use:

parent.removeChild(this);

However, that will not remove the instance from memory, only the display list so it is not seen by the user. If you need the movie clip to be removed from memory, you will need to make sure there are no variables left that reference that movie clip. For class properties, null is used; for dynamic properties, delete.

classPropertyMcRef = null;
delete dynamicMcRef;

This represents a shift in responsibility of object removal from the object being removed to the parent or the timeline containing that object (or even the object that created it if not its parent).

In other words, movie clips should not be held accountable for whether or not they exist. This is the task of whatever object or parent is creating and using that movie clip. The object that created the instance would be (for the most part) the one controlling the references to that instance. By maintaining good encapsulation, it should do its best to prevent that reference to be spread too thinly across other class instances, especially if that movie clip needs to be removed at some point in time. This way that class can maintain all references, remove the instance from the display list when needed, and delete, nullify all references when it has to be removed from memory.

Similarly, you can minimize references or not use them altogether. By assigning unique instnace names to movie clip instances (or other display objects) through their name property, you can easily dynamically obtain a reference when needed using getChildByName("instanceName"). By relying on this method to reference your movie clip instance instead of having other variable references, simply removing the instance from the display list with removeChild(getChildByName("instanceName")) will be all that is needed to remove the instance from memory.

[senocular]

When you create a new ActionScript 3 application/movie, you're working with a main timeline as the "root" of your application. This root that *you* as a developer are working with then gets added to the stage when your main timeline instance is instantiated. This instance represents the root that is a property of DisplayObject. It is your main timeline.

In the property inspector in Flash CS3 you can associate a custom class with your root (aka main timeline) by filling out the document class field (available when nothing on the screen is selected). Whatever class you specify there has to be at least a Sprite, however, since a) it needs to exist as a child of stage and b) because other instances exist within this instance (unless code is used to explicitly move them to stage). If you do not specify a class for the document class Flash will create one for you called MainTimeline. This instance represents the root that is a property of DisplayObject. It is your main timeline.

If you write code in a timeline, you are defining code that will become part of the class definition of that movie clip symbol, or in the case of the main timeline, since it isnt a symbol, definitions specific to the MainTimeline or document class definition. If you both specify a class for the document class AND write code in the main timeline, then you will have to be sure that your document class extends at least MovieClip (instead of Sprite) since you are using frames in that movie clip (to write code) and it will not work for Sprite instances.

In all respects to the developer, the main timeline is the root of the application. Fittingly so, it is also the instance referenced by the root property of DisplayObject instances within that SWF. The root instance, however, is not the absolute root of the display list hierarchy. That title belongs to the stage instance.

The stage instance is an instance of the Stage class which is instantiated when the Flash player starts. It represents the stage or top-most level of the Flash player. SWFs are then loaded into this stage container with their root instances and played as a child of stage. DisplayObject instances have a stage property that reference this Stage instance.

The stage, however, unlike root, cannot be modified by Flash developers. It is always an instance of the Stage class and always the top level of the display hierarchy within the Flash player.

When a SWF is played, it will always start with 2 display objects in the display hierarchy, the stage instance with a single child of the root instance (MainTimeline instance or an instance of your document class if specified). Other instances would be generated by contents of the SWF and are typically children of root (though it is possible to add additional children to stage through ActionScript). Any symbols or graphics in the main timeline in Flash are children of root (as, again, root is the main timeline)

ALL DisplayObject instances have root and stage properties. Each of these properties (when valid) for any display object within a single SWF reference same root and stage instances, there are only one of each (the only exception is the root property of the stage which references the stage). These properties are null if you have an instance who is not a child of a display list within the stage display hierarchy.

For loaded SWFs, the stage properties of its DisplayObject instances will reference the same stage as that referenced in the SWF that loaded it; there can be only one stage. For loaded SWFs, however, the root property will reference that loaded SWF's root, or its main timleine instance, not the root of the SWF that did the loading.

To summarize: one stage, one root per SWF (which is the main timeline) and that root is an instance of a document class or the MainTimeline class if a document class isn't provided

[senocular]

The package specific to Flash CS3 classes and Flash CS3 components is named fl. Non-component classes (like Tween) are located within this package directory located in the folder:
<Flash CS3 Install>/<lang>/Configuration/ActionScript 3.0/Classes/

(For an english Windows installation this is C:\Program Files\Adobe\Adobe Flash CS3\en\Configuration\ActionScript 3.0\Classes\)

This directory is specified in the global class path of Flash. You can see this by selecting:
Edit > Preferences > ActionScript (category) > ActionScript 3.0 Settings... (button)

This makes sure any of the classes within that folder will be accessible to all of your Flash CS3 projects. All you need to do is import them appropriately.

You will notice that component classes are not included in this collection. Component classes (their source) are instead available in the following location:
<Flash CS3 Install>/<lang>/Configuration/Component Source/ActionScript 3.0/

These classes are not specified within a classpath in Flash and are not used when using components in Flash CS3. Instead the ActionScript 3 components in Flash CS3 use pre-compiled versions of these classes located in a compiled clip called ComponentShim provided with the component assets when a component is added to your library.

This is done because ActionScript 3.0 components in Flash CS3 are now FLA based instead of being completely self-contained compiled clips as they were in AS2. Being FLA based, you can open and edit the component states as easily as you could with V1 components. Components that are not compiled clips, however, need to be recompiled every time you publish a SWF. The CS3 AS3 components get around this by using the ComponentShim compiled clip which contains all the compiled component classes allowing those definitions to be quickly added to a published SWF without the need to compile them again from scratch.

If the component source classes were within the classpath defined within Flash (or a FLA's publish settings) those definitions would override those within the ComponentShim and be compiled with the SWF instead. If you ever need to edit the core component classes for one of your projects, you could edit their sources from the component source directory and place them in the classpath of your project allowing those definitions to override those within the ComponentShim (Note: you should always make a copy of the class you wish to edit instead of editing the original).