No _lockroot
 

ActionScript 3 no longer uses the _lockroot property. The _lockroot property was introduced in Flash Player 7 and allowed _root references in loaded movies to continue to reference the loaded movie's _root instead of the _root of the movie which loaded in that movie if the movie was loaded into a MovieClip.

In ActionScript 3, all references to root remain connected to the original root of the file as though _lockroot was already in place.

Flash CS3: Automatic Timeline Declarations
 

When you write custom classes for your Flash documents (Document classes) or movie clip symbols, normally you would need to declare all movie clip (or other child instances) within the class definition. For example, if you are writing a class for a movie clip which contains another movie clip with the instance name "foo", in the class definition you would have to declare foo.

With ActionScript 3 in Flash CS3, you have the option to have Flash make those declarations automatically. To do this check the "Automatically declare stage instances" option in File > Publish Settings > Flash tab > (ActionScript 3) Settings. With that checked, declarations will be done automagically.

Note: If you do not have that option checked and you do not declare your variables you may get an error that looks like:
If you have that option checked and you still declare your variables, you may get an error like:

Property Access and Downcasting
 

When type is assigned to some properties in ActionScript, it's recognized that values of that property may be of different types or be instances of different classes. That property, however, may require that whatever value is used be at least a subclass of a certain type if not that type directly and therefore isn't typed as having no type (*). An example of such a property is the parent property in Display Objects. The parent property in the DisplayObject definition is typed as DisplayObjectContainer. This is the required type for any DisplayObject to contian other DisplayObject instances (and thus becoming their parent). But you'll never find a direct instance of DisplayObjectContainer as a parent of another DisplayObject; you'll only have subclasses like Sprite, or MovieClip, or maybe some custom class. Since they extend the DisplayObjectContainer class the DisplayObjectContainer type remains valid for the parent property.

Here is where a complication exists. As the type DisplayObjectContainer, Flash will only expect properties of the DisplayObjectContainer class to be used with the parent reference. If you attempt to use a non-DisplayObjectContainer property from a parent reference - and this can be a valid property that actually exists in that parent - you will get an error because that property is not recognized in DisplayObjectContainer, the type associated with the parent property. The error will look something like

To get around this error you need to assign the parent reference to a new variable with the type needed downcasting the parent to that type. Before doing this, its always a good idea to make sure the parent is actually the type you are casting to.



Note: for quicker access to a single property when you're sure of the property type, you can just use something like the following:

I've updated the first post with some samples links:


Samples:
Flex 2 AS3 Samples
Flash CS3 Samples

Loading a Cross-domain Policy File
 

Cross-domain policy files (crossdomain.xml) are used by the Flash player to let a web server allow or disallow data to be used in Flash by another domain. ActionScript 3 lets you specify if you want to load and check a cross-domain policy file when you load content from another server (rather than just checking it automatically as was the case with ActionScript 2). This is handled within a LoaderContext (flash.system.LoaderContext) instance.

By default, policy files are not checked; this saves loading time and bandwidth. To assure that Flash checks the necessary policy file when loading content, you would create a new LoaderContext instance, set its checkPolicyFile property (LoaderContext.checkPolicyFile) to true, and pass that instance into your call to load.

Loading External Classes with ApplicationDomain
 

When you load an external ActionScript 3 SWF into a Loader instance in another ActionScript 3 SWF you can have the loaded SWFs definitions be shared with the SWF handling the loading or you can have it completely separated. The location of these definitions is known as the Application Domain.

In ActionScript 3 there is a hierarchy of application domains that describes class relations. You can have application domains separated (thereby keeping definitions separated) or you can an application domain as the child of another application domain. A child application domain will use definitions in its parents' application domains before it uses its own if they are defined in a parent.

When loading a SWF into another SWF you have 3 options for the placement of the loaded SWFs definitions:

• new partitioned domain: create a new separated domain for the loaded SWFs definitions to live that will separate it completely from those definitions within the loading SWF.
• current domain: load the definitions into the current application domain of the loading SWF. This will not overwrite existing definitions but it will add new definitions to those within the current application domain of the SWF doing the loading.
• child domain (default): load the definitions into a new application domain that is a child of the application domain of the loading SWF. This will not affect the current application domain of the loading SWF but it will force the loaded SWF to use any duplicate definitions in the parent over its own

You specify application domains for loaded content within a LoaderContext (flash.system.LoaderContext) instance. This instance is then passed to the load() method of Loader (Loader.load()). For the domain of the current SWF, you can use ApplicationDomain.currentDomain ().



More information:

• http://livedocs.adobe.com/flex/201/h...ng_162_09.html
• http://livedocs.adobe.com/flex/201/h...ent_175_4.html

Save Memory When Reusing Bitmaps With the Same BitmapData
 

Each Bitmap instance in ActionScript 3 references a separate BitmapData instance as a source for its graphics data. When you have two Bitmap instances, you potentially have 2 separate BitmapData instances as well.

If you want to have two Bitmaps that look exactly the same, you can save memory by making both of those bitmaps reference the same BitmapData instance through ActionScript. All you need to do is create the second Bitmap using the BitmapData from the original. Any changes made to the BitmapData instance will affect both Bitmaps on screen.

ActionScript SWFs and Version Compatibility
 

Because ActionScript 3 uses a completely new AVM (ActionScript Virtual Machine) than ActionScript 1 and ActionScript 2, there is limited compatibility between movies created with these different versions of ActionScript. The short of it is this, where AVM1 represents ActionScript 1 and ActionScript 2 movies and AVM2 represents ActionScript 3 movies:

• AVM1 cannot load AVM2
• AVM2 can load AVM2 or AVM1 (but)
• AVM2 can only interact with AS in AVM1 using LocalConnection

Essentially, your ActionScript 1 and 2 movies are not going to be able to interact with ActionScript 3 movies without some work, and it requires that an AS3 movie be used to load in the AS1 or AS2 movie(s).

For more information, read:

• Compatibility with previous versions

That given, what would be the best practice if you want to append HTML text? There doesn't appear to be a similar speedup for HTML, so we're stuck with += - is that correct?

Ooh, also, I'd love to see a tip about making the most of the new debugger. There is much to learn about that beast, since List Variables is now all but empty.

isn't htmltext just a string

same should apply

There isn't an equivalent for HTML text. :sleep:

No no... in AS3.0, the TextField still has both its text and htmlText properties and you can append strings for both using +=.

However, there is a new method applying to text only - appendText(); which is a signficiant speedup over using +=... however, there is no equivalent for htmlText, so if your textbox contains HTML you have to use the "slower" alternative (which is still quick enough, as it has always been :))

the example in #365 is

// create a loader context that
// checks for policy files
var context:LoaderContext = new LoaderContext();
childDefinitions.checkPolicyFile = true;

// use the context with your call to load
myLoader.load(request, context);


why not

context.checkPolicyFile = true;



what's childDefinitions ??

nshen121, thats a typo. I'll fix it now :)

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

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.

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 ?

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

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



What's wrong?

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

Don't know. I'm using:


and in the root:


Why can't I just use root/_root?

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

:D

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.

Use IEventDispatcher to type EventDispatcher objects
 

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.

What removeMovieClip() becomes in ActionScript 3
 

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:

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:

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.

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.

How stage, root, and MainTimeline Fit Together
 

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

Flash CS3: Component Classes
 

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).

This is a great tutorial especially for beginners in AS3 like myself!:thumb:
Thanks again :sen:

Thanks. I'm going to try to include examples to work through next so it will be easier to follow along with :) (especially for the display object section)

senocular, i owe you a ton beers.
thank you so much...

Then I don't know how I'm going to "link" to this root var from the mc.
I'm not using classes.

:(

I dont get what you mean. You're always using classes in AS3
http://www.kirupa.com/forum/showthre...61#post1914661

Also root is a property of all movie clips. If you're writing code in a MovieClip, you have access to root and as long as that movie clip exists on the timeline, that root will be a valid reference to the main timeline
http://www.kirupa.com/forum/showthre...48#post2129548
http://www.kirupa.com/forum/showthre...13#post1952513

Yeah, I meant that I don't use .as-files and own classes/packages and stuff.
Just AS in a .fla-file.

Anyway, "Access of possibly undefined property cells" - I have made a varin the root with the name "cell", so I don't understand why it doesn't find it.

Like I said, you have to cast it to something like MovieClip
http://www.kirupa.com/forum/showthre...40#post2120340

Alright, when i used:



... it seems to work. I don't get any error now, at least. Thanks. :)

Thx
 

Thank you very much for this tip, i've been so worried since i couldn't find any help on this in Flash CS 3 Doc. You really saved my day :)

I can't seem to get a hang on Components in AS3. Is there anywhere a tutorial to clarify all this? I followed flashbrighton.org's tutorial (assets, componentshim, ...) but it just doesn't work.

Are there any simple examples?

I know that you can access the code of the standard AS3 components because their sources are in a folder of flash but they are way to complicated for a beginner-component coder.

Any help? :p

EDIT: the tutorial I followed: http://www.flashbrighton.org/wordpress/?p=31