You can see this in action if you open up two browser windows of this page. The play/stop controls in each embedded movie will only affect the first loaded AVM1Movie instance loaded.

Pperhaps the way to do this is for the AVM1Movie to broadcast on a predetermined statically named LocalConnection to the AVM2 container, informing it of a dynamically (run-time) determined LocalConnection receiving channel name. The AVM2 container movie would have to keep track of each AVM1 instance and it’s dynamic LocalConnection name for when it wants to send commands. It seems like an ugly solution.

I’ll try to get these posts up asap!

Quick question, on p 63 of the book you have a section titled Removing Objects from Memory, you essentially set ball=null to clear it from memory after removing it from the display list. I tried setting my loader to null after I remove it from the display list and it still plays the audio from the loaded swf. So when you say “In short, you need to stop everything you started before you unload….” the loaded swf must be responsible for it’s own cleanup.

thanks again

In short, you need to stop everything you started before you unload. This is good practice anyway, but does require more diligence. For example, stop all sounds and videos, close any sound and video streams, stop all timers (a running timer can never be garbage collected), remove listeners (especially enter frame listeners), and then unload.

That should enable your assets to be collected but, even then, you don’t know when and have no control over the process. This is not a question for lingering sound playback of course, but rather for memory management. This, too, may not be an issue for you if your project is a get-in and get-out type of thing, but it’s important for things like kiosks that run continuously.

If all goes well, we’ll have the loading/unloading material live this week. Thanks!

Great book by the way, I started with Essential ActionScript 3.0 and was overwhelmed.

thanks

For everyone’s benefit, on Friday, we’ll start the series and you’ll be able to follow this thread through a few posts over the ensuing days. However, here’s a quick discussion about AS3 loader/loadee arrangements. I caution you that this is just a discussion, a quick answer to your question, and won’t have the clarity of a proper post. If you have any trouble with my context here, don’t worry, the post will clear it all up and provide sample files. If you can muddle through this, however, it’ll give you a jump start.

For this quick discussion, I’ll assume you are using timeline code (it’s a bit different with classes) and can successfully load a SWF, using the simple example at the top of page 285. Then, in the loaded SWF (called “toLoad” in the example), you can learn about the relationship between the parent and child this way. First, add “trace(parent);” to the “toLoad” file. When you test the loadee, the result will be the stage. When you test the loader you created earlier, the result will the be instance of the Loader class used to load the external SWF.

Next, add “trace(parent.parent);” to the loadee. This will show null when testing the loadee, because there is no parent higher than it’s stage. But in the loader, this will reference the Loader instance’s parent–in this case, the main timeline. You now have a path to talk to the loader from the loadee.

So, as an example, if you have a variable in the loader main timeline, called “loaderVar”, for instance, you can get it’s value this way (theoretically): “trace(parent.parent.loaderVar);” The only issue is that, in Strict Mode (which you should always use), the compiler doesn’t know that loaderVar is a property (variable) of the movie clip (loader main timeline). So, you can explicitly cast the parent as a movie clip (again, assuming, as is true in this example, that the parent is the main timeline of the loader, not another display list child). To do this, all you need to do is add the MovieClip() casting method: “trace(MovieClip(parent.parent).loaderVar);” This way, the compiler knows that loaderVar is a property (variable) of the parent’s parent you are trying to target.

The result is that you can get the variable value in the loader, from within the loadee. You can communicate both ways, trigger functions, etc. Remember that there is a lot to consider here–from how things change in classes, to identifying the parent of the loaded content (if, for example, it’s not the main timeline), to properly unloading the content, to security issues if the loaded content isn’t in the same domain, etc. For the most part, these are not inconsistent with AS2 issues, and are just added layers of concern that come with added complexity.

Stay tuned for the loading/unloading series (see the comment date for time-context) for a more clearly explained post and sample files.

PS: i’m gonna have your Book someday.. i will..