http://richtextformat.co.uk/blog/?p=15 : Freelance Flash & Flex Developer Sat, 25 May 2013 04:43:06 +0000 http://wordpress.org/?v=2.6 http://richtextformat.co.uk/blog/?p=15#comment-51 rich Sun, 16 Dec 2007 18:11:29 +0000 http://richtextformat.co.uk/blog/?p=15#comment-51 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. 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.

]]> http://richtextformat.co.uk/blog/?p=15#comment-4 rich Sun, 16 Dec 2007 13:11:29 +0000 http://richtextformat.co.uk/blog/?p=15#comment-4 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. 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.

]]>