|
History
| Log In
|
|
|
|
Nope. This code is coming directly from the DHTML writer in the tag compiler. I need to dig...
Simple test case:
<canvas> <script> var zot = {}; zot.rsc = {ptype: "sr", frames: ["diamond/client/skin/gloss/silver/tab/tab_dslct_rt.png", "diamond/client/skin/gloss/silver/tab/tab_slct_rt.png", "diamond/client/skin/gloss/silver/tab/tab_mo_rt.png"], width: 9, height: 25}; (function () { Debug.write("hello"); })(); </script> </canvas> Works in swf, bombs in dhtml. simple test case now works but lzmail in webtop shows a different error when compiling to DHTML -
$1.indexOf is not a function setResource(0)LFCdhtml.js (line 2237) (no name)(0)LFCdhtml.js (line 4655) (no name)(Object resource=panelTopLeftResource, Object name=tl $classrootdepth=1)LFCdhtml.js (line 731) (no name)(panel name: panel __LZUID=__U61 _instanceAttrs=Object, Object name=tl $classrootdepth=1, null, true)LFCdhtml.js (line 692) nc()LFCdhtml.js (line 86) (no name)(Object attrs=Object name=view, true)LFCdhtml.js (line 1015) (no name)([This is the canvas hasdatapath=true datapath=Object, [Object attrs=Object name=text, Object attrs=Object name=mailwindow, Object attrs=Object name=contactswindow, 277 more...], LzView name: gAbout id: gAbout __LZUID=__U60 _instanceAttrs=Object, 3 more...], 500)LFCdhtml.js (line 10961) (no name)()LFCdhtml.js (line 10934) (no name)(2625)LFCdhtml.js (line 1679) __idleupdate()LFCdhtml.js (line 12427) __update()LFCdhtml.js (line 1721) [Break on this error] if($1.indexOf("http:")==0||$1.indexOf("https:")==0){ The problem might be LPP-4757. That was a bug that I filed with a workaround back when I did the first & second DHTML passes. I can look into implementing the workaround in the diamond-dhtml branch or you can just fix that one. :)
This is a real bug, it only shows up in debug mode. I have a fix out for review with Don.
If you load with debug mode off, or if you have my fix, then you see the next error that you report above, but that is a new bug (so I will split it off). r7414 | ptw | 2007-11-29 12:32:27 -0500 (Thu, 29 Nov 2007) | 38 lines
Changed paths: M /openlaszlo/trunk/WEB-INF/lps/server/src/org/openlaszlo/sc/Compiler.java Change 20071129-ptw-o by ptw@dueling-banjos.local on 2007-11-29 12:29:35 EST in /Users/ptw/OpenLaszlo/ringding-2 for http://svn.openlaszlo.org/openlaszlo/trunk Summary: Don't try to be so cute about using implicit semicolons in Javascript compiler Bugs Fixed: Technical Reviewer: dda@ddanderson.com (Message-Id: <E9BECAAE-BA1E-4703-A5CD-EE18EBB925D7@ddanderson.com>) QA Reviewer: enw (pending) Details: We used to try to be clever and use newlines in place of semicolons in our 'compressed' code so that the code was a little more human-readable (and debuggable, using the native browser debugger). But this cuteness was just broken and caused some expressions to not be interpreted as statements (and often to be interpreted as function calls). Without a huge amount of work, it is difficult to correctly compute where an implicit semicolon can be used. Instead, we now always end a statement with a semicolon and only elide them before the close brace of a block (which is easily computable). And, we output blocks a little more compactly, actually improving the 'compression' of our Javascript output. The primary change is to remove the old heuristic that inserted semicolons in between statements in a statement list, and to explicitly append one to each statement. Put all the block building in one method instead of inlining it all over the place. Tests: smokecheck, test case in bug, lzmail in DHTML now gets past the reported error (trunk 4 build r7884)
smokecheck and test case in bug run successfully. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
P0
resources in DHTML fail with "is not a function'" error
Can you look at the source file: ../../applib/contacts/style/gloss_silver.lzx#7.94 and see if it is doing something like:
new LzCSSStyleRule();
If it is, you may be able to work around the bug by saying:
new LzCSSStyleRule;
instead. They are equivalent.
It looks to me like the debug annotation that is trying to catch undefined references is confusing the new call into thinking that it is:
(new a)();
rather than:
(new a());
?