Classes within swfs within swfs gotcha
I’ve been bashing my head away at a problem this morning. An AS3 project I’m working on here features a swf within a swf. The encased swf has a bunch of graphics in it most of which are linked to visual classes (classes that extends Sprite, SimpleButton, etc.). Likewise the encasing swf has its own Document class which instantiates a whole other bunch of other abstract and data classes.
Now it just so happens that one of these classes - lets call it ViewClassA - was imported into one of the wrapping abstract classes in the outer swf; not used but just imported. I compiled that swf was compiled yesterday and haven’t touched it since because I’ve been concentrating on the inner swf. ViewClassA was one of the classes linked to a onstage graphic and I’ve been making changes to it over the past 24 hours until I got it to the point this lunchtime that I was happy with it and thus wanted to see how the inner swf looked within and interacted with its wrapper swf.
So I launched the encasing outer swf in a browser and… what is this? All the functionality added over the past day was gone and the trace statements were outputting old content. Eh? OK, so, I cleared the cache, deleted and recompiled the inner swf which was all working nicely and tried again. Same result, what? How puzzling.
I tried this, I tried that: no cigar. Then I was about to head off to a forum and pose a question about this odd behaviour when it struck me that the encasing swf hadn’t been recompiled since yesterday and perhaps it was overwriting the new implementation of ViewClassA with its own embedded version. So I recompiled that too and: bingo! Our inner swf was suddenly kicking out the correct, up-to-date trace content.
So interestingly there is some sort of hierarchy here. There were two versions of the same class existing within the totality of the swf-as-two-swfs and the version accessed was the one stored in the containing outer swf, which embedded the contained inner swf into itself. I gotta get on with some stuff so don’t have time to test this more thoroughly but thought a blog post about it might be useful to anyone out there suffering similar problems.
A good gotcha to be aware of. Heads up everybody!
:)
December 16th, 2007 at 1:11 pm
So just going on from there: what I’ve just discovered is that I don’t even need to bother recompiling the encased swf at all. In my case here the encasing swf loads the encased swf and casts its main timeline MC to the visual class said MC is linked to in the library and, I’m therefore assuming, brings that and any other classes therein (in this case the main timeline MC contains a whole bunch of MCs that link to the aforementioned ViewClassA) into itself anyway. I’m assuming this because having compiled the encased swf I have closed its FLA file, made changes to the ViewClassA trace code, recompiled the encasing swf, cleared the cache and viewed in a browser to see those changes to ViewClassA appear in the output trace. Which is nice, i don’t have to bother recompiling both swfs every time I want an update.
December 16th, 2007 at 1:11 pm
So just going on from there: what I’ve just discovered is that I don’t even need to bother recompiling the encased swf at all. In my case here the encasing swf loads the encased swf and casts its main timeline MC to the visual class said MC is linked to in the library and, I’m therefore assuming, brings that and any other classes therein (in this case the main timeline MC contains a whole bunch of MCs that link to the aforementioned ViewClassA) into itself anyway. I’m assuming this because having compiled the encased swf I have closed its FLA file, made changes to the ViewClassA trace code, recompiled the encasing swf, cleared the cache and viewed in a browser to see those changes to ViewClassA appear in the output trace. Which is nice, i don’t have to bother recompiling both swfs every time I want an update.