<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Drinking from the Fire Hose</title>
	<link>http://www.quip.net/blog/2009/flash/drinking-from-the-fire-hose</link>
	<description>Luck is the residue of good design.</description>
	<pubDate>Mon, 06 Sep 2010 16:43:12 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.2</generator>

	<item>
		<title>by: David Stiller</title>
		<link>http://www.quip.net/blog/2009/flash/drinking-from-the-fire-hose#comment-403403</link>
		<pubDate>Tue, 14 Jul 2009 14:16:34 +0000</pubDate>
		<guid>http://www.quip.net/blog/2009/flash/drinking-from-the-fire-hose#comment-403403</guid>
					<description>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.</description>
		<content:encoded><![CDATA[<p>Mike,</p>
<p>Glad to hear this!  Divide and conquer, man.  Troubleshooting, when it doesn&#8217;t kill you, can actually be kind of fun.  (Yeah, uh huh.)  <img src='http://www.quip.net/blog/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' />   It sounds like you&#8217;re making headway, though, which all that matters.</p>
<p>I don&#8217;t understand all the 1009 errors either, but that&#8217;s a healthy reminder that the learning never stops, no matter who&#8217;s programming.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Mike W</title>
		<link>http://www.quip.net/blog/2009/flash/drinking-from-the-fire-hose#comment-403385</link>
		<pubDate>Tue, 14 Jul 2009 11:00:04 +0000</pubDate>
		<guid>http://www.quip.net/blog/2009/flash/drinking-from-the-fire-hose#comment-403385</guid>
					<description>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</description>
		<content:encoded><![CDATA[<p>Hi David</p>
<p>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!! <img src='http://www.quip.net/blog/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' />  Thanks again for the help, pointers and sounding board opportunity - I&#8217;ll be back&#8230;<br />
Regards<br />
Mike
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: David Stiller</title>
		<link>http://www.quip.net/blog/2009/flash/drinking-from-the-fire-hose#comment-403212</link>
		<pubDate>Mon, 13 Jul 2009 13:43:42 +0000</pubDate>
		<guid>http://www.quip.net/blog/2009/flash/drinking-from-the-fire-hose#comment-403212</guid>
					<description>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 &lt;em&gt;depths&lt;/em&gt; 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 &lt;em&gt;is&lt;/em&gt; frustrating when the &lt;code&gt;trace()&lt;/code&gt; statement loses priority, but fortunately, the divide-and-conquer approach is still a handy way to pinpoint (or &lt;em&gt;begin&lt;/em&gt; to pinpoint) trouble areas.  For example &amp;#8212; and this isn't the most satisfying consolation, I realize &amp;#8212; 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 &lt;code&gt;DisplayObject.ADDED_TO_STAGE&lt;/code&gt; event 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 an &lt;code&gt;ADDED_TO_STAGE&lt;/code&gt; handler in your child.

I'm taking shots in the dark, but I hope this gives you at least &lt;em&gt;something&lt;/em&gt; 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?</description>
		<content:encoded><![CDATA[<p>Mike,</p>
<p>I agree with what you&#8217;re saying about the 1009 error:  like the Blue Screen of Death, it&#8217;s annoying when this error occurs, and its cause is often hard to pinpoint.  That said, I&#8217;m afraid I don&#8217;t have a one-size-fits-all solution for you, even though your description is admirably thorough.  To answer your specific questions:</p>
<p>1) The order of your timeline layers doesn&#8217;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 <em>depths</em> for display in Flash Player.  When the playhead enters a particular frame, ActionScript is always executed before that frame&#8217;s visuals are displayed, no matter where that keyframe&#8217;s layer was stacked, even if there were numerous layers with ActionScript.  So layer stacking isn&#8217;t the culprit here.</p>
<p>2) It <em>is</em> frustrating when the <code>trace()</code> statement loses priority, but fortunately, the divide-and-conquer approach is still a handy way to pinpoint (or <em>begin</em> to pinpoint) trouble areas.  For example &mdash; and this isn&#8217;t the most satisfying consolation, I realize &mdash; you&#8217;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.</p>
<p>That does suggest to me an avenue to try.  It might be that you&#8217;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&#8217;t be valid.  On the off-chance that&#8217;s the culprit here, take look into the <code>DisplayObject.ADDED_TO_STAGE</code> event to see if you can defer those references until the stage is a known entity to the loaded content.  You&#8217;ll want to set up an <code>ADDED_TO_STAGE</code> handler in your child.</p>
<p>I&#8217;m taking shots in the dark, but I hope this gives you at least <em>something</em> to go on.  I do think it&#8217;s interesting that at present, your loaded content displays the background only, without the animation.  Not sure why that&#8217;s happening.</p>
<p>Do you get the same issue(s) when you load these child SWFs into a fresh, new FLA with nothing else in it?
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Mike W</title>
		<link>http://www.quip.net/blog/2009/flash/drinking-from-the-fire-hose#comment-402438</link>
		<pubDate>Thu, 09 Jul 2009 11:25:16 +0000</pubDate>
		<guid>http://www.quip.net/blog/2009/flash/drinking-from-the-fire-hose#comment-402438</guid>
					<description>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</description>
		<content:encoded><![CDATA[<p>Good Day David</p>
<p>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!</p>
<p>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”.</p>
<p>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&#8217;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&#8217;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&#8217;s alpha to 0 and then the movieClip will be instantiated when the call from your custom class is made.”</p>
<p>Easier said than done – or maybe my lack of experience here with AS3.</p>
<p>(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?</p>
<p>(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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Thanks and Regards<br />
Mike
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
