Came across this one the other day..
In my new job, I’m working with a really good flash coder who tends to completely abstract all presentation away from his code. Whereas I’m used to simply extending the MovieClip class to act as a base for my classes, he tends to employ a less Flash-constrained approach and passes the class instance a reference to a drawing clip for all the presentation needs.
I see the benefits of working this way, so I thought I’d give it a go in our latest project and got myself a bug from hell where I couldn’t load an image into a clip, whose reference I’d passed the loader class. After hours of poring through the classes, double checking logic for loopholes and ( most importantly, making sure the jpg wasn’t progressive) we hit upon the answer:
Instead of using the MovieClip class, we have our own class, that creates movieclips, add extra properties/methods and manages depths (useful when publishing to FP6). The one thing it didn’t do, however, is name your new MovieClips, so you’d end up with a load of mainly numeric clip names. This is fine if you’re just using references throughout your classes and never open the debugger, but I’m in the habit of using the debugger to quickly view clip properties and – as my classes extend movieclip and are attached with via the package – class properties, so I was creating my clips and then altering the _name property.
This wasn’t so much of a problem, but I was passing freshly created clips into the constructors of classes and then changing the name of the clip in the next line of code.
The constructors were storing references to the ‘drawing clips’, but as soon as I changed the clip name, the reference was broken.
The upshot is that references are resolved using the targetPath of a movieclip and not as a pointer to a memory address. So if you’re going to change the names of your clips, make sure you haven’t made any references to them first!!
!! 🙁 !!