I’ve got a problem, I understand why it’s happening, and I have the solution. I’m looking for a different solution though, because on a large scale project the solution can easily become a hassle and result in many extraneous files. So here we go with the explanation…
I have a file LittleClass.fla which has a document class LittleClass.as. LittleClass.fla contains one library item that is exported for Actionscript with a class name of LibraryItem. LittleClass.as defines one public function called doSomething() that has the following line:
var myItem:LibraryItem = new LibraryItem();
I publish this file to LittleClass.swf no problem.
I have a second file BigClass.fla which has a document class BigClass.as. In BigClass.as, the code loads LittleClass.swf, then tries to call doSomething(). Now in order to not throw compiler errors, BigClass.as needs to know LittleClass’s class definition, so at the top of BigClass.as I put the line:
import LittleClass;
Because of this, when publishing BigClass.fla, it recompiles LittleClass.as. But BigClass has no access to LibraryItem that is stored inside LittleClass.fla, and it throws the compile errors:
1046: Type was not found or was not a compile-time constant: LibraryItem
1180: Call to a possibly undefined method LibraryItem
I completely understand why this is happening, but I can’t believe that there’s not a simple solution to what I imagine is a very common scenario: 2 separately published swf files that want to call public methods on one another.
Solution A: For each library item that has a class, create an actual .as file for it with just the bare bones of a class definition. Then in the document class, import the path to every .as file. That way all class definitions are made in external files, and are visible to any class that needs to import the document class in order to gain visibility of the public methods defined within.
Problem: If you’ve got 5 library items, this isn’t that bad. if you’ve got 50, it starts to really suck. If you’ve got 200…
Solution B: In the document class, define a proxy class to use for every library item, like so:
var ProxyClassA:Class = getDefinitionByName("LibraryClassA") as Class;
and use weak typing for any variable declarations that will have one of these items assigned to it:
var libItemInstance:* = new ProxyClassA();
Problem: Less tedium than the previous solution, but there’s still an additional line of code for every library class. Plus you lose some valuable compile-time checking by weak-typing the variables.
Solution C: Don’t use library items. Pull everything out and load at runtime using Loader, Sound, Video, or whatever respective external file loading method you need.
Problem: Self-explanatory. The only reason I wouldn’t do this in the first place is because these are usually just graphics without any functionality that I want to be able to quickly grab again and again. Going this route would bring back all the extra variables and loading processes that using a library item helps avoid.
For now, Solution B is the route I’m going to take. But I would love to hear some other people’s thoughts on this. Other solutions, or ways to just avoid the problem in the first place. But again, it’s caused by such a common situation: accessing public methods/variables/properties between swfs that contain library items that are referenced by class name. I would think that interacting swfs is such a wildly common thing that Adobe would have found a simple solution. Even more surprising is that I don’t see many threads discussing this problem, which makes me wonder if I’m missing something obvious.
Thanks!
