Drinking from the Fire Hose
A good friend of mine, Branden Hall, uses a startling metaphor to describe what it’s like when scheduling has gone insane, when too many projects are due at once, and when, in general, “overwhelmed” isn’t a strong enough adjective. He aptly calls this feeling “drinking from the fire hose,” which fairly describes how I felt while writing my books last year. Somehow, the image always makes me chuckle.
It’s been about six months since I last wrote an entry here, and that’s much too long! A handful of regular readers have even checked in to ask what’s going on, which I appreciate. The simple truth is that I’ve been catching up on things other than Flash (and work in general), and it has honestly taken this much time. In fact, I’m still not as caught up as I’d like. (For example, I have nearly two hundred comments to get to from this blog! I feel awful about the delay — some messages are easily a year old — but I keep chipping away at them and do intend to eventually work my way through.)
For the record, I’m still very involved with Flash, as much as I ever have been. I still use Flash every day and, honest to goodness, still love my job. The only thing that’s changed, really, is that I’ve significantly reduced the amount of time I work in the evenings and weekends. It was getting pretty unhealthy there for a while! Instead of working, I’ve been spending time with my wife and daughter, which has been an absolute boon to my sanity. It also means I’ve been sticking to my New Year’s resolution for 2009. 
In fact, I’ve even indulged in a few new hobbies, including homemade cheese, gardening, and bread making … things I have to do with my hands, away from the keyboard. In short, life is good. 
Ironically, this return to “the simple things” occasionally increases the stress of my work day, because it means I have to get things done during normal business hours, rather than into the evening. I do put in “overtime” every now and then, as everyone does, but I’ve had a goal for quite some time to make that the exception to the rule, rather than the norm. I do feel like I’m making strides, even if it takes a while.
I recently started recording video tutorials for an online training center, partly to market Foundation Flash CS4 for Designers (friends of ED). I’ll mention when those are ready. I’m also still writing articles for CommunityMX.com and have been percolating a few ideas to continue helping folks make the transition from ActionScript 2.0 to 3.0. More on that down the line, when time allows. I do plan to keep writing Flash tutorials for this blog, as soon as I can wrangle my calendar into place.
Thanks for the patience!
July 9th, 2009 at 6:25 am
Good Day David
My second cry for guidance on your great weblog. I searched around and cannot find a specific existing thread that covers my problem in full, so I’ve posted here. Please move it as appropriate or open a new AS3 thread. I think this is quite a widespread problem!
TypeError: Error #1009: Cannot access a property or method of a null object reference – as painful as the classic Window’s blue screen of “death”.
From what I can glean via the Net (and from Curtis Morley’s blog (http://curtismorley.com/) in particular), this error basically means that you are trying to reference something that isn’t there yet. That something can be a variable, data from the server, or even a movieClip or other display instance. The writer goes on to say that one reason for this is “…because you are trying to access a movieClip that isn’t instantiated yet. For example you try and reference a movieClip named loader_mc that is inside another movieClip you are referencing it from a class that you created. Each time you run the test the movie you get the Run-Time Error #1009. You look inside your movieClip and see that the loader_mc is right where you want it. It is on frame 10 inside your animated moveiClip. That is when it dawns on you that the call to loader_mc happens when it is instantiated. Simply, put loader_mc on frame 1 and change it’s alpha to 0 and then the movieClip will be instantiated when the call from your custom class is made.”
Easier said than done – or maybe my lack of experience here with AS3.
(1) First off – just a quick technical question (based on this error) : When the AS3 is compiled at runtime along with the layers of the timeline, is there a specific order that the compilation takes place? My timeline only has one frame but 10 layers in Flash CS4. I lay items out on the stage and give them instance names on the lower layers (bottom) and my AS3 is on the top layer. I still get 1009 errors (it is more complicated than this…). Does this have anything to do with the order of compilation of the layers?
(2) I read your article on AS3 and debugging using the ”trace” command. However this, together with the great AS3 debugger, does not appear to pinpoint #1009 errors correctly – the debugger merely “falls over” at whichever line it happens to be when the 1009 error establishes itself. Removing or commenting out THAT line just causes the debugger to fall through and error on the next line when run again, etc.
Basically the application (e-learning) I’m working on comprises a main “driver” SWF which is made up of a movie clip frame with navigation buttons below. This main driver swf is ONE FRAME ‘long’ laid out on ten separate layers (hence the description earlier with the compilation question). On running, the main driver loads the first external SWF of the training content and runs through it until it ends [stop(); in the final frame of the loaded external swf file]. The learner then clicks the NEXT button (or BACK, AGAIN, etc) and the next (or previous etc) external swf is loaded into the “stage” movie clip frame. The buttons and loading is all done with functions in the main driver. TRACE shows that the correct swf names are being generated by the functions. The external swf’s are loaded using a LOADER event and a URL request with an ADD CHILD call putting them onto the main stage within the display movie clip frame.
The anomaly is – static content in an external swf displays fine without #1009 error. External swf files with timeline animations (work fine on their own) generate the #1009 error shortly after the load is initiated and display the background only but with no animation.
I’ve looked, I’ve tried some suggested work-arounds like putting in a blank frame at frame 1 of the external swf (doesn’t work in my case and does not seem to be the correct method anyway), everything – still getting the error. I can ‘understand’ why its being generated (instantiation of objects etc.) but I cannot find the answer to overcome and eradicate it. Can you please help or guide or point me to a source of possible help.
Thanks and Regards
Mike
July 13th, 2009 at 8:43 am
Mike,
I agree with what you’re saying about the 1009 error: like the Blue Screen of Death, it’s annoying when this error occurs, and its cause is often hard to pinpoint. That said, I’m afraid I don’t have a one-size-fits-all solution for you, even though your description is admirably thorough. To answer your specific questions:
1) The order of your timeline layers doesn’t affect the ActionScript compiler. In fact, timeline layers are little more than an illusory convenience during authoring. When the SWF is compiled, those layers are gone, having been converted into depths for display in Flash Player. When the playhead enters a particular frame, ActionScript is always executed before that frame’s visuals are displayed, no matter where that keyframe’s layer was stacked, even if there were numerous layers with ActionScript. So layer stacking isn’t the culprit here.
2) It is frustrating when the
trace()statement loses priority, but fortunately, the divide-and-conquer approach is still a handy way to pinpoint (or begin to pinpoint) trouble areas. For example — and this isn’t the most satisfying consolation, I realize — you’re at least aware that the error occurs when a particular set of external SWFs is loaded. The tricky part is, those SWFs seem to test out fine when run on their own.That does suggest to me an avenue to try. It might be that you’re making references to the stage in your loaded (that is, child SWF) content. If those references are evaluated before the loaded content is added to the stage, they won’t be valid. On the off-chance that’s the culprit here, take look into the
DisplayObject.ADDED_TO_STAGEevent to see if you can defer those references until the stage is a known entity to the loaded content. You’ll want to set up anADDED_TO_STAGEhandler in your child.I’m taking shots in the dark, but I hope this gives you at least something to go on. I do think it’s interesting that at present, your loaded content displays the background only, without the animation. Not sure why that’s happening.
Do you get the same issue(s) when you load these child SWFs into a fresh, new FLA with nothing else in it?
July 14th, 2009 at 6:00 am
Hi David
Thanks for the response. I took your last comment and ran with it. I kept the basics of the training application shell and stripped all the AS3 code away except for the loader. The external animated SWF loaded AND RAN without error. At the moment I am now adding back functionality code a little at a time so that I can see at what point what falls over. Had a few hiccups with the unload but seem to have sorted it out. Will continue and let you know the outcome. Do I understand it all (1009 errors) - NO - not at all. They are still as spurious and cunning as ever - but I guess they all happen for a reason although it does sometimes make me yearn back for my C++ days!!
Thanks again for the help, pointers and sounding board opportunity - I’ll be back…
Regards
Mike
July 14th, 2009 at 9:16 am
Mike,
Glad to hear this! Divide and conquer, man. Troubleshooting, when it doesn’t kill you, can actually be kind of fun. (Yeah, uh huh.)
It sounds like you’re making headway, though, which all that matters.
I don’t understand all the 1009 errors either, but that’s a healthy reminder that the learning never stops, no matter who’s programming.