you're right I have to do it again on another machine but actually I did a
fresh download of the 4.4.1 OSX release today and just run into that.

sebastian

2009/7/24 P T Withington <[email protected]>

> Even without the debug player, shouldn't the LZX debugger catch the runtime
> error and give at least /some/ information?
>
> I agree with you that Sebastian must have a more subtle error that is
> confusing the compiler, so it would be great if he could create a test
> case.
>
>
> On Jul 24, 2009, at 14:40, Henry Minsky <[email protected]> wrote:
>
> Are you talking about compile time errors or runtime errors?
>
> Can you give an example of a compile time error that stops the compiler?
>
> I tried a simple example like this with a method that the compiler knows
> does not exist at compile time:
>
> <canvas>
>     <text bgcolor="#ccffcc" text="${canvas.runtime}">
>       <handler name="oninit">
>         LzView.nosuchmethod();
>       </handler>
>     </text>
> </canvas>
>
> The error reported does localize properly to the lzx file source code line
> number
>
>
> The application could not be compiled due to the following errors:
> Compilation Errorsorg.openlaszlo.sc.CompilerError: hello.lzx: 4: Error:
> Call to a possibly undefined method nosuchmethod through a reference with
> static type Class, in line: LzView.nosuchmethod()
>
> It may be however that your example is doing something that confuses the
> LPS compiler in a way that it is unable to parse out the flex compiler error
> message and transform it back to LZX source code filename and line numbers,
> so it would help to see you specific example.
>
>
> For a runtime error, like below, the compiler does not know whether the
> method exists, because 'canvas' in this example is declared as a dynamic
> variable which may have properties added at runtime:
>
> <canvas>
>     <text bgcolor="#ccffcc" text="${canvas.runtime}">
>       <handler name="oninit">
>         canvas.nosuchmethod();
>       </handler>
>     </text>
> </canvas>
>
>
> But when it runs, it gives a runtime error in the Flash debug player.
>
> TypeError: Error #1006: nosuchmethod is not a function.
>     at $lzc$class_$2Fcanvas$2Ftext/$m4()
>     at Function/ <http://adobe.com/AS3/2006/builtin::call%28%29>
> http://adobe.com/AS3/2006/builtin::call()
>     at LzEvent/sendEvent()
>     at LzNode/__LZcallInit()
>     at LzCanvas/__LZcallInit()
>     at LzCanvas/__LZinstantiationDone()
>     at LzInstantiatorService/makeSomeViews()
>     at LzInstantiatorService/checkQ()
>     at Function/ <http://adobe.com/AS3/2006/builtin::call%28%29>
> http://adobe.com/AS3/2006/builtin::call()
>     at LzEvent/sendEvent()
>     at LzIdleKernel$/__update()
>
>
> If runtime errors, are you running with the Flash Debug player?
>
> On Fri, Jul 24, 2009 at 2:24 PM, Sebastian Wagner <<[email protected]>
> [email protected]> wrote:
>
>> I think you can quite easy make a compiler issue like that cause every
>> time you write in your code a call to a method or attribute that does not
>> exist, that hole Compiler does stop and quite.
>>
>> thanks,
>> sebastian
>>
>> 2009/7/24 P T Withington < <[email protected]>[email protected]>
>>
>> Henry and Raju have given lots of hints. I'll just add that when you find
>>> out the cause, please file a bug if you can. Clearly we would like this not
>>> to happen.
>>>
>>>
>>> On Jul 24, 2009, at 7:28, Sebastian Wagner < <[email protected]>
>>> [email protected]> wrote:
>>>
>>> hi,
>>>
>>> actually you run into a lot of compilation issues when you run a previous
>>> application into SWF9.
>>> I followed the SWF9 Migration Guide of course, the code has zero problems
>>> to be compiled to SWF8.
>>> I guess in most cases its something very tiny tricky in the code that
>>> needs to be changed but actually you don't get anything except
>>> *org.openlaszlo.sc.CompilerError: Errors from compiler, output file not
>>> created*
>>> The console does also only pring:
>>> FAIL: compiler returned 1 ... or another number
>>>
>>> So how do you get those Compile Errors?
>>> I guess they are not really that handy as they will show you only errors
>>> in the resulting ActionScript that is going to be compiled by the Flex
>>> compiler.
>>> So you will not see which LZX-Codeline has the error.
>>> But without any notice at which code-block to look at its almost
>>> impossible to migrate more then a bunch of code lines with every
>>> compilation.
>>>
>>> I've seen that there are some properties in the configuration:
>>> compiler.swf9.warnings=false
>>> compiler.swf9.execflex=true
>>> # Tell compiler to catch errors in debug mode
>>> compiler.catcherrors=true
>>>
>>> changing them does seem to have an effect.
>>>
>>> Is there a clue that is hidden somewhere or how do you judge what needs
>>> to be done when you run into this?
>>>
>>> thanks,
>>> sebastian
>>>
>>> --
>>> Sebastian Wagner
>>> <http://www.webbase-design.de> <http://www.webbase-design.de>
>>> http://www.webbase-design.de
>>> <http://openmeetings.googlecode.com><http://openmeetings.googlecode.com>
>>> http://openmeetings.googlecode.com
>>>  <http://www.laszlo-forum.de> <http://www.laszlo-forum.de>
>>> http://www.laszlo-forum.de
>>> <[email protected]> <[email protected]>[email protected]
>>>
>>>
>>
>>
>> --
>> Sebastian Wagner
>> <http://www.webbase-design.de>http://www.webbase-design.de
>>  <http://openmeetings.googlecode.com>http://openmeetings.googlecode.com
>>  <http://www.laszlo-forum.de>http://www.laszlo-forum.de
>> <[email protected]>[email protected]
>>
>
>
>
> --
> Henry Minsky
> Software Architect
> <[email protected]>[email protected]
>
>
>


-- 
Sebastian Wagner
http://www.webbase-design.de
http://openmeetings.googlecode.com
http://www.laszlo-forum.de
[email protected]

Reply via email to