Bug report: ContentDisplay is not removed

[Ahrengot]

I think the following is a bug, as the documentation states that unload() on LoaderMax does the following: "Removes any content that was loaded ..." however the ContentDisplay classes is still kept in my container in the following example:

 

I have a _mainLoader LoaderMax containing ImageLoader's. It's a simple gallery with next/previous functionality and when next/previous is called, the LoaderMax flushes it's content and a new image is loaded. However ContentDisplay instances aren't being removed from their container correctly.

 

Setup of the loader, event handlers etc. - _images is an Array containing strings(url's to the images)

public class SimpleGallery extends Sprite
{
//	Images
private var _images:Array;
private var _index:int = -1;

//	Container
private var _imageHolder:Sprite;

//	Loading
private var _mainLoader:LoaderMax;

public function SimpleGallery($images:Array) 
{
_images = $images;

addEventListener(Event.ADDED_TO_STAGE, init, false, 0, true);
}

private function init(e:Event):void 
{
removeEventListener(Event.ADDED_TO_STAGE, init);
addEventListener(Event.REMOVED_FROM_STAGE, destroy, false, 0 , true);

_imageHolder = new Sprite();
addChild(_imageHolder);

setupGallery();
}

private function setupGallery():void
{
_mainLoader = new LoaderMax( { name:"mainLoader", auditSize:true, onChildProgress:handleProgress, onChildComplete:handleComplete, onError:handleErrors } );
loadNext();
}

private function handleProgress(e:LoaderEvent):void
{
trace(this + " load progress: " + int(ImageLoader(e.target).progress * 100) + "%");
}

private function handleComplete(e:LoaderEvent):void
{
trace(this + " Loader " + ImageLoader(e.target).name + " successfully loaded: " + ImageLoader(e.target).url);
dispatchEvent(new Event(Event.CHANGE));
}

private function handleErrors(e:LoaderEvent):void
{
trace(this + " ERROR loading on loader " + ImageLoader(e.target).name + " loading image: " + ImageLoader(e.target).url);
}

 

clearMainLoader method:

private function clearMainLoader():void
{
_mainLoader.unload();
_mainLoader.empty();

var i:int = _imageHolder.numChildren;

trace(this + " clearMainLoader() found " + i + " children in _imageHolder. Removing them now.");

while (i--) 
{
	//_imageHolder.removeChildAt(i);
}
}

Now, if i don't uncomment that '_imageHolder.removeChildAt(i);' line the content keeps piling up in _imageHolder.

 

Next previous methods:

/**
* Loads the next image in the provided array
*/
public function loadNext():void
{
_index++
if (_index == _images.length) _index = 0;

clearMainLoader();
_mainLoader.append(new ImageLoader(_images[_index], { container:_imageHolder } ));
_mainLoader.load();
}

/**
* Loads the previous image in the provided array
*/
public function loadPrevious():void
{
_index--
if (_index == -1) _index = _images.length - 1;

clearMainLoader();
_mainLoader.append(new ImageLoader(_images[_index], { container:_imageHolder } ));
_mainLoader.load();
}

[Ahrengot]

To clarify, the images themselves are being removed. I tried setting the alpha on loaded content to 0.5 and there are never 2 images above each other, but the ContentDisplay is left behind.

 

the following traces: "[object SimpleGallery] Stuff left behind: [object ContentDisplay]"

private function clearMainLoader():void
{
_mainLoader.unload();
_mainLoader.empty();

var i:int = _imageHolder.numChildren;

trace(this + " clearMainLoader() found " + i + " children in _imageHolder. Removing them now.");

while (i--) 
{
	//_imageHolder.removeChildAt(i);
	trace(this + " Stuff left behind: " + _imageHolder.getChildAt(i));
}
}

[GreenSock]

Yep, this isn't a bug - it's by design although I can see why it would be a bit confusing at first. The thing is that I didn't think it would be desirable to remove the ContentDisplay if you added it to your application. It unloads the rawContent of course (the image itself) but the container ContentDisplay is left so that you can reload the content if you want. See what I mean? In other words, if you did:

 

myLoader.unload();

myLoader.url = "newFile.jpg"

myLoader.load();

 

It would load the content back into the ContentLoader that was assigned to the loader. But if I physically remove the ContentDisplay from its parent, that would break the functionality.

 

My choices (as I see them) are:

 

1) Update the docs to make it more clear that ContentDisplay instances are left alone when you unload()

 

-OR-

 

2) Force the ContentDisplay to be removed from its container (if it has one) on unload()

 

Thoughts? Suggestions?

[Ahrengot]

Ahh yeah, it makes sense in the context where you're just unloading the current content to load some other content, but what confuses me, it is still left behind after you call both the unload() and dispose() method.

 

What i'm looking for is a way to remove EVERYTHING on the loader classes when i'm done using them.

 

would there be any reason not to remove ContentDisplay on unload() and add it again if the user calls load()? It seems like you've already thought out almost every possible scenario, so i'm just trying to learn how to best use these awesome classes

[clipclicmusic]

Hi

 

I would tend to agree.... I don't build enormous apps, so this is maybe lazy on my part...

 

I use LoaderMax to load stuff in the background, then use the cache of the browser to reuse it when the user needs it.

A memory problem occurs if I do that and use dispose int he class, as it were

 

Perhaps the best bet is ANOTHER config option whereby the loader AND the content is disposed of once loaded ? I suspect these Background Loaders are more common that we all think ?

 

Best

 

Jason

[GreenSock]

I added a new "flushContent" parameter to the dispose() method which will trigger SWFLoader, ImageLoader, and VideoLoader to destroy their ContentDisplay as well. So instead of unload() and dispose(), you can now do dispose(true). The previous behavior with unload() still stands, so it won't remove the ContentDisplay instance from the display list - I think this is important because in many cases, you'll want to keep it there. Kinda like Adobe's Loader which you can unload() but the Loader itself still stays so that you can load() other stuff in there.

 

Make sense? This seemed like the best compromise as it gives you the ability to completely destroy a loader and its content while providing the flexibility to just unload() its content or dispose() of the loader instance in a mutually exclusive way.

 

Agreed?

 

(the latest version has these changes - https://www.greensock.com/account/)

[Ahrengot]

Yes, that seems like the best way to go. Thanks a lot