After further investigation, it may be specific to Flash's NetConnection object and how it calls back the onStatus function, or there is something else odd going on. Unexpectedly, my code does not fail when I do the same thing with a NetStream object.
added comment to bug On Fri, Jun 16, 2006 at 9:12 AM, P T Withington wrote: > Oh bummer. So its a player bug. That is going to be harder to track > down, and to work around... > > On 2006-06-16, at 09:31 EDT, Sarah Allen wrote: > >> >> Reported as bug: >> http://www.openlaszlo.org/jira/browse/LPP-2197 >> >> I was using the swf7 default and saw the bug in Flash Player 7 not >> in Flash Player 8 >> No change in behavior for swf6. I didn't test swf8. >> >> Sarah >> >> On Thu, Jun 15, 2006 at 8:21 PM, P T Withington wrote: >> >>> Closures are supposed to work. I believe they work in AS as of >>> swf6. But our compiler plays several tricks a) to implement >>> implicit this, b) to work around a Flash but in function contexts, >>> and c) to implement our 'implicit this' rules. It is entirely >>> possible you have unearthed a bug here. Please report. >>> >>> Could you clarify what target you are compiling for? Always swf7 >>> but running on the 7 vs. 8 player? Or are you compiling for >>> different targets? >>> >>> As to the comment that you cannot close over `this`, that is a >>> canard. `this` is an implicitly defined local, defined >>> automatically in every function (just as `arguments` is). So it is >>> not that you cannot close over it, it's just that every function >>> will automatically shadow its parent's `this` and `arguments`. If >>> an inner function needs to refer to either of those bindings in its >>> parent, the parent needs to create an alias that will not be >>> shadowed. >>> >>> On 2006-06-15, at 19:57 EDT, Sarah Allen wrote: >>> >>>> >>>> So, that differed from Flash Player 7 to Flash Player 8? >>>> Is there any way we could smooth out that difference in the >>>> compiler? >>>> >>>> On Thu, Jun 15, 2006 at 4:45 PM, Adam Wolff wrote: >>>> >>>>> it's the behavior of closures. to make this compatible, you could >>>>> add >>>>> a >>>>> property to the function, and then retrive it using >>>>> arguments.callee >>>>> >>>>> this._nc.onStatus = function(info) { >>>>> _root.Debug.write('onStatus ', info.code); >>>>> _root.Debug.write('this ', >>>>> arguments.callee.originalthis >>>>> ); >>>>> } >>>>> >>>>> this._nc.onStatus.originalthis = this; >>>>> >>>>> >>>>> A >>>>> >>>>> On Jun 15, Sarah Allen wrote: >>>>> >>>>>> >>>>>> You are so right. It's a Flash Player 7 vs. Flash Player 8 >>>>>> issue, >>>>>> consistent >>>>>> across Mac & Windows. >>>>>> I'm still puzzled though. The NetConnection object was >>>>>> introduced in >>>>>> Flash >>>>>> Player 6. >>>>>> >>>>>> >>>>>> On Thu, Jun 15, 2006 at 3:28 PM, Adam Wolff wrote: >>>>>> >>>>>>> same flash player version? >>>>>>> >>>>>>> On Jun 15, Sarah Allen wrote: >>>>>>> >>>>>>>> >>>>>>>> I have some code that I just started testing on other machines >>>>>>>> today, and >>>>>>>> unexpectedly, I started seeing different (broken) behavior on a >>>>>>>> Mac. I've >>>>>>>> isolated it down to the following test case: >>>>>>>> >>>>>>>> <canvas> >>>>>>>> <node> >>>>>>>> <!--- a reference to the Flash NetConnection object >>>>>>>> @keywords private --> >>>>>>>> <attribute name="_nc" value="null" /> >>>>>>>> >>>>>>>> <method name="init"> >>>>>>>> super.init(); >>>>>>>> this._nc = new NetConnection(); >>>>>>>> >>>>>>>> var ok = this._nc.connect('rtmp://localhost/test'); >>>>>>>> var t = this; >>>>>>>> this._nc.onStatus = function(info) { >>>>>>>> _root.Debug.write('onStatus ', info.code); >>>>>>>> _root.Debug.write('this (t) ', t); // this is >>>>>>>> line >>>>>>>> 17 >>>>>>>> } >>>>>>>> </method> >>>>>>>> </node> >>>>>>>> </canvas> >>>>>>>> >>>>>>>> which generates the following: >>>>>>>> WARNING: test.lzx:17: reference to undefined variable 't' >>>>>>>> this (t) undefined >>>>>>>> >>>>>>>> Confused again, >>>>>>>> Sarah >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Laszlo-dev mailing list >>>>>>>> [email protected] >>>>>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev >>>>>>>> >>>>>> >>>>>> >>>> >>>> _______________________________________________ >>>> Laszlo-dev mailing list >>>> [email protected] >>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev >>> >> > _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
