Understanding class "fingerprints" with SWC files

[kaveri2]

I'm sorry for a very poorly structured question. I just run out of English... I hope one of you guess what's the problem and can provide better words to describe it!

I'm having hard time understanding how classes from SWC files are handled when the app is complied with Flash Builder. We have about 50 SWC files, all compiled from corresponding FLA files. Their libraries contain elements that have AS3 linkages and in the end, there are plenty of classes involved. The classes are packaged in SWC files and Flash Builder finds them just fine. Some AS3 linkages have the same name, which is OK, because they are essentially the same library elements and we don't want to have duplicates in the app. Also plenty of AS3 linkages have same base classes, which means plenty of SWC files carry those base class definitions too, but only one is really needed.

Sometimes everything works, sometimes something breaks. It almost seems like the moon phase affects whether the end result works or not... Sometimes recompiling SWC files helps with one problem, but breaks something else. This leads me to guess, that Flash Builder selects the available classes based on the date of the SWC files? If more than one SWC files have the same class definition, Flash Builder selects the newest?

The error we encounter, is "AS3 Error #1034: Type Coercion failed:", which is related to having one of these shared AS3 linkages (let's say SharedClass) on the timeline of a MovieClip. This means it is *not* created with the new keyword! So if SharedClass is defined in SWC1 and SWC2, maybe Flash Builder decides to use the one from SWC1. This means that elements from SWC2 that use SharedClass will use SWC1's definition of it. But for some reason this doesn't always work as it should. It helped, when I changed how AS3 references the instances declared on the timeline: "var mySharedClassObject:SharedClass" --> "var mySharedClassObject:*" but I don't understand why...

This leads me to believe, that the SharedClass in SWC1 and SWC2 have different "fingerprints" which makes the class casting break in some situations. When I use "new" keyword, everything works, because it doesn't matter which definition will be used. But when the class is created on the timeline, it may require exact fingerprint of that class?

Most of those cases are easily cleaned, but I'm also running into problems with some classes that have only one definition! If the AS3 linkage of SWC1 has the same base class, than AS3 linkage of SWC2, we run into the same problem. This is because both SWC1 and SWC2 contain the definition of the base class and maybe they have different fingerprints, even though our base classes are just AS3 files (no linkages).

Does this make any sense?

Anyone know a way to see the class name collisions and potential problems?

[Colin Holgate]

If different SWC are using exactly the same class, there’s no problem. If more than one is using the same named class, and the two or more copies are different, they it’s down to the order they get compiled, and that can vary.

Make sure that everywhere that a class has the same name, it’s identical to the other ones. Remember that MovieClips become classes too, so if you have a shared library item named “title”, and it’s different for each SWC because the graphic instead the MovieClip is different, then you’ll get big problems.

One easy solution is to put the classes into a dedicated folder, like:

src/com/yourname/game1/Title.as

and:

src/com/yourname/game2/Title.as

instead of:

src/com/yourname/games/Title.as

You will end up with a lot of identical things in memory, but they have a different path, and won’t clash with each other.

Another thing to know, if you use GetDefinitionByName(“class1”), the main document class needs to know about those classes. This will solve that problem:

public var namedClasses:Array = [class1,class2,class3];

Then when the compiler is doing its thing, it doesn’t go into shock when an embedded SWC is creating an instance of a class from the shared name.

So, make sure things are truly identical, or make sure they have a different path.

[kaveri2]

Thanks for editing the missing reply Colin.

I have identical classes defined in multiple SWC files, and have problems. As I tried to explain, using the classes on timeline (not code), triggers the error. I was wondering if timeline creates the instances differently.

I'm using the class array trick and GetDefinitionByName, they work beautifully for dynamically creating stuff!

[kaveri2]

I encountered similar error in a very clear context. I have a helper SWF, which creates instances of Tween class. The mechanism how these two SWF files communicate is quite complex, so I can't show the real code. But basically it goes like this:

var t:Tween = complexMechanism.tweenCreator.create(...);

Which produces runtime error: TypeError: Error #1034: Type Coercion failed: cannot convert fl.transitions::Tween@7fff8d0ff29 to fl.transitions.Tween.

If I don't specify the type, everything works fine:

var t:* = complexMechanism.tweenCreator.create(...);

t.start();

I did a few initial tests and found that Array object works fine... Also the code works on SWC-environment. So when Flash Builder compiles everything into one app, they end up sharing the same Tween class. In SWF-environment each SWF has own class definitions?

The strange part is, that I encounter this problem now. Either this is a new thing, or I have just always used * type before...

[Colin Holgate]

For some reason my first reply didn't show up, so I've edited that just for historical interest.

Here's a new thought: Does your class extend Tween? If it doesn't then it isn't a Tween. Do both your document class and the custom class include the line:

import fl.transitions.Tween;

?

BTW, I have seen cases where I had to use the full path to the class, like:

var thingy:com.company.Thingy = new com.company.Thingy();

If I just did:

import com.company.Thingy;

var thingy:Thingy = new Thingy();

it would fail. Not sure why.

[kaveri2]

My Tween builder SWF creates and returns basic Tween objects, so no inheritance there. I tried using full class name, but got the same error. But this occurred only in SWF to SWF communication, which may be because they have different sandboxes, so different class definitions. The code worked just fine in SWC. So getting back to my mail message, it seems the problem is instantiating in timeline.