Now that Flash CS5 is out, it seems that many users have been trying to use workflows to which they are accustomed with TLF text and have been having problems. We did know that there would be some problems like this with TLF, but I think we really underestimated the pain it would cause people, so apologies for that.
The main problem (there are others, but maybe another post sometime for all that) occurs when you a SWF that uses TLF and you intend to load that SWF using Loader or UILoader into another application and you want to do scripting across the parent and child, even if it is as simple as calling something like
Because of the way we do the runtime shared library (RSL) preloading for TLF with the default options set, this doesn’t work as you would expect. There is actually a tech note about this on adobe.com at http://kb2.adobe.com/cps/838/cpsid_83812.html.. However, it needs some corrections as currently written, so I’d like to explain those and also to clarify things a bit here.
SafeLoader work around
First, I would like to evangelize a bit for the SafeLoader solution, listed as solution 2. Really I would list that as solution 1. It is a class that emulates the Loader’s API, but is not in fact a Loader or a subclass of Loader, and if you use the SafeLoader instead of Loader, then you can simply load a child SWF that uses TLF as normal and everything will just work. Even better, you can use the SafeLoader to load a child SWF that does not use TLF and everything will just work.
Typically all you need to do to use the SafeLoader is:
- Download the source from the tech note and install the files SafeLoader.as and SafeLoaderInfo.as in the folder structure fl/display next to your FLA file (or somewhere else in your source path).
- In your source import fl.display.SafeLoader
- Search and replace through your source, replacing all instances of Loader with SafeLoader
The SafeLoader.zip file includes some FLA files which are examples of how to use the SafeLoader class and you don’t really need those, but you can check them out. Honestly it is a little embarrassing that they included those files with the download. Now you can see the pathetic level of design skill the typical engineer on the Flash pro team has. We draw a lot of ellipses.
If you are wondering, why didn’t we ship the SafeLoader with Flash? It was something that we put together very late in the game and there was not time.
Custom preloader loop work around
Now on to what is listed in the tech note as solution 1. This is really two solutions which have been munged together.
So the one that I would recommend first is to leave the runtime shared library (RSL) default linkage set to RSL and change the preloader method to custom preloader loop. (This custom preloader loop thing is another topic that really needs its own blog post.) This setting is changed in the Library path tab of the Advanced ActionScript 3.0 Settings Dialog, which you can raise from the document level property inspector. The dialog is shown below with its default settings.
After changing the preloader method to custom preloader loop, you then must follow the steps outlined in the tech note (and not after setting the default linkage to merged into code as the note states):
- Leave frame one in the main timeline of the child SWF empty. Your content, including frame scripts, should start on frame 2.
- In the Advance ActionScript 3.0 Settings Dialog, set Export Classes in frame 2.
Part of the problem with this method is that while your child SWF will load and run correctly when you put it in the parent, you actually may get runtime errors when you test movie the child SWF and try to work with it individually. If this happens, the way to work around it is to temporarily go into the Advanced ActionScript 3.0 Settings Dialog and switch the default llinkage to be merged into code. Then you would need to remember to set it back when you do your final publish. I think you can see why I recommend SafeLoader over this!
Merged into code work around
This is a simple work around, but it has a major draw back. You simply go into the Advanced ActionScript 3.0 Settings Dialog and set default linkage to merged into code for any child SWF that uses TLF.
The major drawback here is that now every child SWF that uses TLF is going to link the whole TLF library in, which is going to increase the size of that SWF by about 120k for every SWF. However, if you download TLF as an RSL, we have set it up to be downloaded as a cross domain RSL, also known as a SWZ file or a signed, cached RSL. This means that a user will only ever need to download the TLF library once for every single site that uses it. So chances are pretty good that if you set up TLF to be downloaded as an RSL, that your flash application will not even need to be the one that causes that extra 120k to download, but that it will already be there, ready and waiting.
So hope that helps clarify the work arounds for this very annoying problem.