Dispatching custom events between child SWFs in AS3

Jeff dePascale — Tue, 25 Aug 2009 19:05:58 +0000

I've written about this before, but this time around I have an answer to this one. The issue goes a little something like this:

a parent SWF

a child SWF, dispatches a custom event

another child swf, nested in either the parent or the other child, listens for that custom event.

The error you'll receive is a type coercion error that looks like a mistake - can't convert [custom event name] to [custom event name]. So what gives? They're the same class, both SWF files have imported the event class correctly, yet they are colliding through the event dispatch. Well, it turns out it is a security violation due to the way in which the SWF was loaded. Change your loader context to new LoaderContext(false, ApplicationDomain.currentDomain) when loading in those child SWFs and suddenly they can talk to each other more openly than before and type checking correctly returns that all important 'true' - in other words, no coercion error. All of those imported classes match up - and you can even instantiate objects of a type defined in the other child SWF without importing it into your class. To get Flash to export it without referencing it though requires a SWC file for the SWF to reference the classes from (CS4 modified this process a bit with the ability to specify external libs, and Flex has had the same functionality for a while i believe). Colin Moock's Essential Actionscript has a chapter on doing just that, right at the end of the book. If you're interested in that process, he says it better than i ever could.

FYI - the fix mentioned in my previous post on the subject is still valid if you can't/don't want to change the application domain for the loader. Adding the reference to the document class of the top level parent SWF still rectifies the issue.

Custom Events in loaded SWF files

Jeff dePascale — Wed, 11 Mar 2009 00:01:33 +0000

Custom events that override the clone method of Event implemented in a loaded SWF file that has listeners in the parent or above will fail with a 1034 coercion error, even though the error seemingly says that the type it is coercing to is the same class type. After much searching I found the answer i needed - something i've come across before when building fosfr. I'm not entirely clear on why this only affects custom events with clone overriden and not others, but the solution is to import the custom event in the root document class and reference an instance of it, thereby forcing the root displayObject to include the event class in its compile. From that point forward it is accessible throughout the SWF hierarchy. You don't need to create an actual instance of the event, just reference it by name. Example:

package {
import my.custom.CustomEvent;

public class Main extends MovieClip {

CustomEvent;

pubic function Main(){
}
}
}

This is definitely required in Fosfr projects given the aformentioned use case. Note that it doesnt appear to cause issues when not listening down in the display list, like this case specifies. Listening up is fine, dispatching up is not.

Hopefully that'll save some of you the hour it took me to find that answer!

Jeff dePascale » events

Dispatching custom events between child SWFs in AS3

Custom Events in loaded SWF files