I think you are looking too closely! :) The LZX still works the same as it always did. Your code should not have to change. It's just that the debugger is now revealing a little more of the internal structure of the Javascript that is generated by the LZX compiler.
This is perhaps a general issue with debuggers. Our debugger is not what you would call a "source level" debugger, because it does not operate on LZX, but rather on the generated Javascript. I've tried to make it a little more friendly by using the LZX tag names for things where I could, but in the end, you do have to understand a little about the LZX -> Javascript translation to fully understand what the debugger is reporting. On 2010-05-10, at 09:31, Raju Bitter wrote: > Ok, I looked at the generated AS3 code, which makes it clear. Thanks! I've > using 4.0.18 for a long time now, and have to get back to using OL 4.7. ;-) > > Thanks, > Raju > > On Sun, May 9, 2010 at 12:02 AM, Henry Minsky <[email protected]>wrote: > >> Well it's a subclass of your original class, so all the instance vars will >> be visible, and >> you can call all the methods you expect. If you want to refer to the class >> itself, you can >> use subclassof operator or instanceof operator (or 'is' operator) >> >> >> On Sat, May 8, 2010 at 5:51 AM, Raju Bitter < >> [email protected]> wrote: >> >>> There's one question left: How do you map "this" within the anonymous >>> class' method to the correct object based on the LZX code structure? >>> >>> On Fri, May 7, 2010 at 11:20 PM, Raju Bitter < >>> [email protected]> wrote: >>> >>>> Thanks for the clarification, Henry. That makes sense. >>>> >>>> >>>> On Fri, May 7, 2010 at 10:47 PM, Henry Minsky >>>> <[email protected]>wrote: >>>> >>>>> When we modified the compiler to generate Actionscript 3, we made it >>>>> generate actual >>>>> method declarations for handlers, both for efficiency and also so you >>>>> can reference >>>>> other instance vars in the "implicit this" scope of the instance. So if >>>>> we're making method >>>>> declarations, we need a class to put them in. If you define any methods >>>>> in an instance, or >>>>> define any constraints on it, it magically builds an anonymous class for >>>>> your instance. >>>>> >>>>> This is defnitely an extra level of complexity for people if they look >>>>> under the covers at what is being done, although in practice it's pretty >>>>> much invisible to users. >>>>> >>>>> >>>>> >>>>> On Fri, May 7, 2010 at 4:16 PM, Raju Bitter < >>>>> [email protected]> wrote: >>>>> >>>>>> Have a look at this code: >>>>>> >>>>>> <canvas width="100%" height="600" debug="true"> >>>>>> >>>>>> <class name="test1" extends="view"> >>>>>> </class> >>>>>> >>>>>> <test1 x="100" y="100" width="100" height="100" bgcolor="#ff0000"> >>>>>> <handler name="onclick" args="p"> >>>>>> Debug.write(this); >>>>>> Debug.write(parent); >>>>>> </handler> >>>>>> >>>>>> <handler name="onclick" reference="b1" args="p"> >>>>>> Debug.info("Event received by " + p); >>>>>> Debug.write(this); >>>>>> Debug.write(parent); >>>>>> </handler> >>>>>> </test1> >>>>>> >>>>>> <button id="b1" text="Click me" /> >>>>>> >>>>>> </canvas> >>>>>> >>>>>> When I click on the button, the onclick handler within test1 is called. >>>>>> But "this" is an anonymous class extending test1. That's not very >>>>>> logical, >>>>>> is it? I can imagine there was a good reason that you have to generate a >>>>>> separate sprite object here, but it's very hard for programmers to >>>>>> understand the underlying object structure. Is that the new way of >>>>>> dealing >>>>>> with handlers? >>>>>> >>>>>> Thanks, >>>>>> Raju >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Henry Minsky >>>>> Software Architect >>>>> [email protected] >>>>> >>>>> >>>>> >>>> >>> >> >> >> -- >> Henry Minsky >> Software Architect >> [email protected] >> >> >>
