[Laszlo-dev] where does the flex compiler think "parent" is being bound in this event handler?

[Amy Muntz]

Hi Ono-san,
DevilDog is the branch that has the swf9-specific work.
RingDing is where we are finalizing the DHTMl work, and
this will become 4.1.
-- Amy

On Thu, Jan 10, 2008 at  7:30 PM, keiji Ono wrote:

Sorry, the email sent on its own. :)
Again.
Thanks Henry.
Rinding would not support swf9 ?
I thought it in ver 4.1, but the wiki roadmap has reminded me did not
say such that.

ono

Henry Minsky wrote:
Yes,we are working on making the  Openlaszlo compiler emit code which is 
sent to the mxmlc compiler, in order to produce swf9 applications.

Work is starting in the subversion  branch named "devildog". We  are 
working on some of the core infrastructure for compiling in swf9, and
will soon be at a point where many people can help with the swf9 
runtime. We have several important issues that we are working on right 
now,
including generating real "native" (as3) class declarations for user 
defined LZX classes. When that is done, then we can use a lot of help 
getting
all the various runtime modules working and optimized for swf9.




On Jan 10, 2008 12:34 AM, keiji Ono < keiji_ono at net8.co.jp 
<mailto:keiji_ono at net8.co.jp> > wrote:
May i come inside ?
Dose not this issue mean what will be able to compile lzx code with 
mxmlc, dose this ?

ono

Henry Minsky wrote: Yeah, we're going to need to do that no matter what 
because we need setters to be able to call "super()"

On Jan 9, 2008 11:23 PM, P T Withington < ptw at openlaszlo.org 
<mailto:ptw at openlaszlo.org> > wrote:
Well I thought our handlers were supposed to be compiled with
'implicit this'.

Perhaps Don left this out, because this _is_ implicit in AS3 method
bodies?  If so, we should make the tag compiler output anonymous
handlers like this as methods not functions.  This would mean we would
have to start emitting those anonymous singleton classes for views
that add methods...

On 2008-01-09, at 23:06 EST, Henry Minsky wrote:

>  I've got a little test LZX code that has a click handler like this:
> <view id="bar" x="200" y="200" >    <view id="foo" bgcolor="0xcccccc" 
> x="-100" y="-100"  height="200" width="200" 
> onclick="parent.animate('rotation', 360, 1500, true)"
>>
>
> When I compile it I get this error from the  flex compiler
> /cygdrive/c/flex2/bin/mxmlc -debug=true 
> -library-path+=../../../lps/includes/lfc/LFC9.lzl  -default-size 800 
> 600 -default-frame-rate 60 DemoApp.as Loading configuration file 
> C:\flex2\frameworks\flex-config.xml 
> C:\users\hqm\openlaszlo\devildog\WEB-INF\lps\lfc\DemoApp.as(49): col: 
> 20 Error: Call to a possibly undefined method animate through a 
> reference with static type flash.display:DisplayObjectContainer.
>            parent.animate('rotation', 360, 1500, true) 
> ^
> The handler is compiled to a function inside of the usual stuff passed 
> to a call to LzInstiateView:
>
> LzInstantiateView({attrs: {id: "bar",                           x: 
> 200,                           y: 200},                   children: 
> [{attrs:                               {$delegates: ["onclick", "$m1", 
> null, "oninit", "$m2_foo_reference", null], 
> $m1: function foo_$m1() { 
> parent.animate('rotation', 360, 1500, true)                    }, ...
>
> So I am not sure in what context the compiler thinks that "parent" is 
> being looked up.
>
> If I change the code to refer to "this.parent", it compiles happily, 
> and appears to work
>   <view id="bar" x="200" y="200" >    <view id="foo" 
> bgcolor="0xcccccc" x="-100" y="-100"  height="200" width="200" 
> onclick="this.parent.animate('rotation', 360, 1500, true)"
>>
>
>
>
> -- 
> Henry Minsky Software Architect hminsky at laszlosystems.com 
> <mailto:hminsky at laszlosystems.com>

  <mailto:hminsky at laszlosystems.com>


-- 
Henry Minsky
Software Architect
hminsky at laszlosystems.com <mailto:hminsky at laszlosystems.com>


-- 
Henry Minsky
Software Architect
hminsky at laszlosystems.com <mailto:hminsky at laszlosystems.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20080110/219dd787/attachment.html