Indicates whether or not the loader's bytesTotal value has been set by any of the following:

• Defining an estimatedBytes in the vars object passed to the constructor
• Calling auditSize() and getting a response (an error is also considered a response)
• When a LoaderMax instance begins loading, it will automatically force a call to auditSize() for any of its children that don't have an estimatedBytes defined. You can disable this behavior by passing auditSize:false through the constructor's vars object.

An array containing the content of each loader inside the LoaderMax

The class used by ImageLoaders, SWFLoaders, and VideoLoaders to create the containers into which they'll dump their rawContent - by default it is the com.greensock.loading.display.ContentDisplay class but if you're using Flex, it is typically best to change this to com.greensock.loading.display.FlexContentDisplay. You only need to do this once, like
import com.greensock.loading.LoaderMax;
import com.greensock.loading.display.FlexContentDisplay;
LoaderMax.contentDisplayClass = FlexContentDisplay;

Controls the default value of auditSize in LoaderMax instances (normally true). For most situations, the auditSize feature is very convenient for ensuring that the overall progress of LoaderMax instances is reported accurately, but when working with very large quantities of files that have no estimatedBytes defined, some developers prefer to turn auditSize off by default. Of course you can always override the default for individual LoaderMax instances by defining an auditSize value in the vars parameter of the constructor.

The default value that will be used for the estimatedBytes on loaders that don't declare one in the vars parameter of the constructor.

Maximum number of simultaneous connections that should be used while loading the LoaderMax queue. A higher number will generally result in faster overall load times for the group. The default is 2. This value is instance-based, not system-wide, so if you have two LoaderMax instances that both have a maxConnections value of 3 and they are both loading, there could be up to 6 connections at a time total.

Number of child loaders currently contained in the LoaderMax instance (does not include deeply nested loaders - only children). To get the quantity of all children including nested ones, use getChildren(true, true).length

See also

An unweighted value between 0 and 1 indicating the overall loading progress of the LoaderMax - this calculation does not concern itself whatsoever with bytesLoaded and bytesTotal but rather the ratio of the children that are loaded (all having equal weight). Therefore, rawProgress is a more crude way of measuring the overall loading progress and isn't weighted in terms of file size the way that progress is. The only benefit of using rawProgress instead of progress is that there is never a risk of the value moving backwards the way it can with progress when child loaders have inaccurately low estimatedByte values (before LoaderMax audits the file size values). The rate at which rawProgress increases may slow down or speed up depending on the file size of the asset currently loading. For example, if a LoaderMax contains two loaders, the first for a file that's 100k and the second for a file that's 10,000k, rawProgress will move quickly (while loading the 100k file) until it reaches 0.5 and then slow down significantly (while loading the 10,000k file) until it reaches 1.

Or let's say you have a LoaderMax that contains 3 ImageLoaders: the first two must load images that are 25k each and the 3rd one must load an image that's 450k. After the first two ImageLoaders finish, the LoaderMax's progress property would report 0.1 (50k loaded out of 500k total) whereas the rawProgress would report 0.66 (2 loaders out of 3 total have completed). However, if you set the estimatedBytes of all of the ImageLoaders in this example to 25600 (25k) and set the LoaderMax's auditSize to false, the progress would read about 0.66 after the first two ImageLoaders complete (it still thinks they're all 25k) and then when the 3rd one starts loading and LoaderMax finds out that it's 450k, the bytesTotal would automatically adjust and the progress would jump backwards to 0.1 (which correctly reflects the weighted progress). Of course a solution would be to more accurately set the estimatedBytes and/or leave auditSize true in the LoaderMax, but rawProgress can be useful if those solutions are undesirable in your scenario and you need to avoid any backwards adjustment of a preloader progress bar or some other interface element.

See also

If skipFailed is true (the default), any failed loaders in the queue will be skipped. Otherwise, the LoaderMax will stop when it hits a failed loader and the LoaderMax's status will become LoaderStatus.FAILED. Skipped loaders are also ignored when the LoaderMax determines its bytesLoaded, bytesTotal, and progress values.

If skipPaused is true (the default), any paused loaders in the queue will be skipped. Otherwise, the LoaderMax will stop when it hits a paused loader and the LoaderMax's status will become LoaderStatus.FAILED. Skipped loaders are also ignored when the LoaderMax determines its bytesLoaded, bytesTotal, and progress values.

Integer code indicating the loader's status; options are LoaderStatus.READY, LoaderStatus.LOADING, LoaderStatus.COMPLETE, LoaderStatus.PAUSED, and LoaderStatus.DISPOSED.

Constructor

See also

Activates particular loader classes (like ImageLoader, SWFLoader, etc.) so that they can be recognized inside the parse() method and XMLLoader. For example, if LoaderMax.parse("image.jpg") is called without first activating ImageLoader (like LoaderMax.activate([ImageLoader])), it wouldn't properly recognize the ".jpg" extension and return the necessary ImageLoader instance. Likewise, without activating ImageLoader first, XMLLoader wouldn't be able to recognize <ImageLoader> nodes nested inside an XML file. You only need to activate() the loader classes once in your swf. For example:

LoaderMax.activate([ImageLoader, SWFLoader, MP3Loader, DataLoader, CSSLoader]);

The reason all loaders aren't activated by default is to conserve file size.

Appends a loader to the end of the queue.

See also

Attempts loading just enough of the content to accurately determine the bytesTotal in order to improve the accuracy of the progress property. Once the bytesTotal has been determined or the auditSize() attempt fails due to an error (typically IO_ERROR or SECURITY_ERROR), the auditedSize property will be set to true. Auditing the size opens a URLStream that will be closed as soon as a response is received.

Empties the LoaderMax of all its loaders and optionally disposes/unloads them.

See also

Finds the index position of a particular loader in the LoaderMax. Index values are always zero-based, meaning the first position is 0, the second is 1, the third is 2, etc.

See also

Returns and array of all child loaders inside the LoaderMax, optionally exposing more deeply nested instances as well (like loaders inside a child LoaderMax instance).

See also

Returns and array of child loaders that currently have a particular status. For example, to find all loaders inside the LoaderMax instance that are actively in the process of loading:

loader.getChildrenByStatus(LoaderStatus.LOADING, false);

See also

Finds the content of a loader based on its name or url. For example:

var image:Bitmap = queue.getContent("myPhoto1");

Feel free to use the static LoaderMax.getContent() method instead of the instance-based getContent() method because the static one will search ALL loaders (the only exception being loaders in a different security sandbox, like in subloaded swfs from a different domain that didn't have a crossdomain.xml file in place granting permission).

See also

Finds a loader based on its name or url. For example:

var loader:ImageLoader = queue.getLoader("myPhoto1");

Feel free to use the static LoaderMax.getLoader() method instead of the instance-based getLoader() method because the static one will search ALL loaders (the only exception being loaders in a different security sandbox, like in subloaded swfs from a different domain that didn't have a crossdomain.xml file in place granting permission).

See also

Inserts a loader at a particular position in the queue. Index values are zero-based just like arrays. For example, if the LoaderMax has 10 loaders in it already and you want to insert a loader at the 3rd position (index: 2) while moving the others back in the queue (like the way splice() works in arrays), you'd do:

queue.insert( new ImageLoader("img/photo.jpg"), 2);

When a new loader is added to the LoaderMax, the LoaderMax's status changes to LoaderStatus.READY unless it is paused or disposed. If the loader is already in the queue, it will be removed first.

See also

Analyzes a url or array of urls and attempts to automatically create the appropriate loader(s) based on file extension(s) in the url(s), returning either an individual loader like an ImageLoader, SWFLoader, XMLLoader, etc or if an array is passed in, a LoaderMax will be returned containing a child for each parsed url (or URLRequest) in the array. Arrays may also contain LoaderCore instances (not just url Strings). For example:

import com.greensock.loading.*;
import com.greensock.loading.core.*;
import com.greensock.events.LoaderEvent;
 
//activate the necessary loaders so that their file extensions can be recognized (do this once)
LoaderMax.activate([ImageLoader, SWFLoader, XMLLoader]);

//now parse a url and create the correct type of loader (an ImageLoader in this case because the file extension is ".jpg")
var loader:LoaderCore = LoaderMax.parse("../img/photo1.jpg", {name:"parsedLoader", onComplete:completeHandler});
 
//begin loading
loader.load();
 
function completeHandler(event:LoaderEvent):void {
 trace("finished loading " + event.target);
}
 

import com.greensock.loading.*;
import com.greensock.events.LoaderEvent;
 
//activate the necessary loaders so that their file extensions can be recognized (do this once)
LoaderMax.activate([ImageLoader, SWFLoader, XMLLoader, MP3Loader]);
 
var urls:Array = ["img/photo1.jpg","../../xml/data.xml","swf/main.swf","http://www.greensock.com/audio/music.mp3"];

//now parse all of the urls, creating a LoaderMax that contains the correct type of loaders (an ImageLoader, XMLLoader, SWFLoader, and MP3Loader respectively)
var loader:LoaderMax = LoaderMax.parse(urls, {name:"mainQueue", onComplete:completeHandler}) as LoaderMax;
 
//begin loading
loader.load();
 
function completeHandler(event:LoaderEvent):void {
 trace("finished loading " + loader.numChildren + " loaders.");
}
 

Prepends a loader at the beginning of the queue (append() adds the loader to the end whereas prepend() adds it to the beginning).

See also

Immediately prepends a value to the beginning of each child loader's url. For example, if the "myLoaderMax" instance contains 3 ImageLoaders with the urls "image1.jpg", "image2.jpg", and "image3.jpg" and you'd like to add "http://www.greensock.com/images/" to the beginning of them all, you'd do:

myLoaderMax.prependURLs("http://www.greensock.com/images/", false);

Now the ImageLoader urls would be "http://www.greensock.com/images/image1.jpg", "http://www.greensock.com/images/image2.jpg", and "http://www.greensock.com/images/image3.jpg" respectively.

prependURLs() permanently affects each child loader's url meaning that LoaderMax.getContent("image1.jpg") would not find the loader whose url is now "http://www.greensock.com/images/image1.jpg" (although you could simply use its name instead of its url to find it). It also means that if a single loader has been inserted into multiple LoaderMax instances, its url change affects them all.

prependURLs() only affects loaders that are children of the LoaderMax when the method is called - it does not affect loaders that are inserted later.

prependURLs() does NOT affect any alternateURL values that are defined for each child loader.

See also

Immediately prioritizes a loader inside any LoaderMax instances that contain it, forcing it to the top position in their queue and optionally calls load() immediately as well. If one of its parent LoaderMax instances is currently loading a different loader, that one will be temporarily cancelled.

By contrast, when load() is called, it doesn't change the loader's position/index in any LoaderMax queues. For example, if a LoaderMax is working on loading the first object in its queue, you can call load() on the 20th item and it will honor your request without changing its index in the queue. prioritize(), however, affects the position in the queue and optionally loads it immediately as well.

So even if your LoaderMax hasn't begun loading yet, you could prioritize(false) a loader and it will rise to the top of all LoaderMax instances to which it belongs, but not start loading yet. If the goal is to load something immediately, you can just use the load() method.

For example, to immediately prioritize the loader named "myPhoto1":

LoaderMax.prioritize("myPhoto1");

Removes a loader from the LoaderMax.

See also

Immediately replaces a certain substring in each child loader's url with another string, making it simple to do something like change "{imageDirectory}image1.jpg" to "http://www.greensock.com/images/image1.jpg". For example, if the "myLoaderMax" instance contains 3 ImageLoaders with the urls "{imageDirectory}image1.jpg", "{imageDirectory}image2.jpg", and "{imageDirectory}image3.jpg" and you'd like to replace {imageDirectory} with http://www.greensock.com/images/ you'd do:

myLoaderMax.replaceURLText("{imageDirectory}", "http://www.greensock.com/images/", false);

Now the ImageLoader urls would be "http://www.greensock.com/images/image1.jpg", "http://www.greensock.com/images/image2.jpg", and "http://www.greensock.com/images/image3.jpg" respectively.

replaceURLText() permanently affects each child loader's url meaning that LoaderMax.getContent("image1.jpg") would not find the loader whose url is now "http://www.greensock.com/images/image1.jpg" (although you could simply use its name instead of its url to find it). It also means that if a single loader has been inserted into multiple LoaderMax instances, its url change affects them all.

replaceURLText() only affects loaders that are children of the LoaderMax when the method is called - it does not affect loaders that are inserted later.

replaceURLText() does affect alternateURL values for child loaders.

See also

Dispatched when any child of the LoaderMax instance dispatches a CANCEL event which could occur when another child is prioritized in the queue or when the LoaderMax is canceled while loading the child. CHILD_CANCEL can be dispatched even if the LoaderMax itself isn't in the process of loading (because load() or prioritize() could have been called directly on a child loader)

Dispatched when any child of the LoaderMax instance completes. So if a LoaderMax contains 5 loaders, the CHILD_COMPLETE event will be dispatched 5 times during the course of the LoaderMax's load. This can occur even if the LoaderMax itself isn't in the process of loading (because load() or prioritize() could have been called directly on a child loader)

Dispatched when any child of the LoaderMax instance fails to load. This occurs even if the LoaderMax itself isn't in the process of loading (because load() or prioritize() could have been called directly on a child loader)

Dispatched when any child of the LoaderMax instance starts loading. So if a LoaderMax contains 5 loaders, the CHILD_OPEN event will be dispatched 5 times during the course of the LoaderMax's load. This can occur even if the LoaderMax itself isn't in the process of loading (because load() or prioritize() could have been called directly on a child loader)

Dispatched when any child of the LoaderMax instance dispatches a PROGRESS event. This can occur even if the LoaderMax itself isn't in the process of loading (because load() or prioritize() could have been called directly on a child loader)

Dispatched when any child of the LoaderMax instance dispatches an HTTP_STATUS event. This can occur even if the LoaderMax itself isn't in the process of loading (because load() or prioritize() could have been called directly on a child loader)

Dispatched when any child of the LoaderMax instance dispatches an IO_ERROR event. This can occur even if the LoaderMax itself isn't in the process of loading (because load() or prioritize() could have been called directly on a child loader)

Dispatched when any child of the LoaderMax instance dispatches a SCRIPT_ACCESS_DENIED event. This can occur even if the LoaderMax itself isn't in the process of loading (because load() or prioritize() could have been called directly on a child loader)

Dispatched when any child of the LoaderMax instance dispatches a SECURITY_ERROR event. This can occur even if the LoaderMax itself isn't in the process of loading (because load() or prioritize() could have been called directly on a child loader)