TECHNICALLY this is feasible, but a bad idea. You'd need to register a callback which would call the child swf (generally done from the child swf). But, you will risk a good deal of headache, and you'll have to rely a lot more on the browser than other options. It would also be slower than an AS only solution.
You're much better off (in this order):
-
Using a shared Singleton. This allows for complete separation of the two
swf's without requiring any major coordination between the two. The only
real potential problem can be caused if you want the child swf to have its
own
ApplicationDomain
, but even with that, there are work-arounds
-
Using events. This can work if you have the child swf dispatch a bubbling,
non-cancel-able event and have the
event.target
recorded by the
parent swf. You may have to adjust to avoid
SecuritySandboxViolation
s, however.
-
Using LocalConnections. The two detriments to LocalConnections are:
- You will need to continually re-generate unique connection names to
avoid the error thrown by connecting two LocalConnections to the same
channel.
- LocalConnections do have bandwidth limitations which can call
slowdowns if there is a high volume of traffic or if the messages are
too large.
-
Using direct manipulations like
loader.content.foo.bar.baz
;
I don't like this solution because it is much harder to maintain. It is
also much worse from a design perspective: you want to use
encapsulation as much as possible in this situation -- this technique
actively works against that.