LzError#149 is not an error number, this is how the debugger abbreviates objects whose printed representation would exceed Debug.printLength. You can try clicking on the error to inspect it to see what the error really is, or you can set Debug.printLength = Infinity before running your program. But we would have to see the actual error message to help.
On 2006-03-21 01:27 EST, Partha Sarathi Das wrote: > Hi, > I am getting an error like LzError#149 in the Debug window.It is > working > fine at the first time in a search application and populated my > Backend Data > properly.But if I choose another search criteria and click on > Search Button > then it is showing the error mesage at the Debug Window and new > result data > is not populating.I am using Laszlo version 3.1.1.Will anybody help > regarding the Bug at ? > Thanks and Regards, > Partha Sarathi Das, > Marisoft , Kalyani Nagar, > Pune,India > [EMAIL PROTECTED], > www.cybage.com > Ph.(Office) : 91 20 56041700 Ext. 2812 > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Saturday, February 18, 2006 6:13 AM > Subject: Laszlo-user Digest, Vol 16, Issue 32 > > >> Send Laszlo-user mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://www.openlaszlo.org/mailman/listinfo/laszlo-user >> or, via email, send a message with subject or body 'help' to >> [EMAIL PROTECTED] >> >> You can reach the person managing the list at >> [EMAIL PROTECTED] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Laszlo-user digest..." >> >> >> Today's Topics: >> >> 1. Re[2]: [Laszlo-user] Changing a nodes parent (Michael Pliskin) >> 2. Re: Deployment and LzBrowser related question (Michael Pliskin) >> 3. Re: nested views and performance (Michael Pliskin) >> 4. Runtime Performance (Paul Younger) >> 5. Re: Runtime Performance (Sarah Allen) >> >> >> --------------------------------------------------------------------- >> - >> >> Message: 1 >> Date: Sat, 18 Feb 2006 00:29:51 +0300 >> From: Michael Pliskin <[EMAIL PROTECTED]> >> Subject: Re[2]: [Laszlo-user] Changing a nodes parent >> To: "Paul Younger" <[EMAIL PROTECTED]> >> Cc: [email protected] >> Message-ID: <[EMAIL PROTECTED]> >> Content-Type: text/plain; charset="us-ascii" >> >> An HTML attachment was scrubbed... >> URL: > http://openlaszlo.org/pipermail/laszlo-user/attachments/20060218/ > c47a389e/at > tachment-0001.html >> >> ------------------------------ >> >> Message: 2 >> Date: Sat, 18 Feb 2006 00:31:52 +0300 >> From: Michael Pliskin <[EMAIL PROTECTED]> >> Subject: Re: [Laszlo-user] Deployment and LzBrowser related question >> To: "James Howe" <[EMAIL PROTECTED]> >> Cc: "[email protected]" <[email protected]> >> Message-ID: <[EMAIL PROTECTED]> >> Content-Type: text/plain; charset=us-ascii >> >> Hello James, >> >> I guess you should just do some string magic in the string >> getLoadURL() gives you - i.e. remove everything after 'lps' or >> whatever. Another way is to invoke some JS function on the HTML >> page >> but this is quite non-trivial (requires fscommand usage probably). >> >> JH> I'm deploying my Laszlo application and I've configured an > Apache/Tomcat >> JH> environment to launch the application just by going to a >> particular > web >> JH> site (e.g. http://foo.bar.com) I have an index.html file which > contains >> JH> the deployment code generated by Laszlo. The application >> launches > just >> JH> fine and works fine. I have a 'Log Off' button which does the > following: >> >> JH> LzBrowser.loadURL(LzBrowser.getLoadURL()); >> >> JH> The problem is that when this code gets executed, the URL isn't >> JH> http://foo.bar.com, but rather >> JH> http://foo.bar.com/lps-3.1.1/blah/blah.lzx?blah=blah&blah=blah? >> etc >> >> JH> Without hardcoding the URL, how can I configure things so that >> the >> JH> application gets reloaded using the same URL that launched it? >> >> -- >> Regards, >> Mike mailto:[EMAIL PROTECTED] >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Sat, 18 Feb 2006 00:33:00 +0300 >> From: Michael Pliskin <[EMAIL PROTECTED]> >> Subject: Re: [Laszlo-user] nested views and performance >> To: "William Krick" <[EMAIL PROTECTED]> >> Cc: Laszlo-User <[email protected]> >> Message-ID: <[EMAIL PROTECTED]> >> Content-Type: text/plain; charset=us-ascii >> >> Hello William, >> >> I think this statement is quite true here as well, more views == >> slower. However, I don't think I have any specific statistics for >> layouts. >> >> WK> Does it make any difference performance-wise if I design my >> app using > nested >> WK> views and layouts vs. explicit positioning using x and y? >> >> WK> I'm used to Java swing development where the mantra is "more >> objects > == >> WK> slower" but I'm not sure if any thing similar exists in laszlo. >> >> -- >> Regards, >> Mike mailto:[EMAIL PROTECTED] >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Fri, 17 Feb 2006 17:12:58 -0500 >> From: "Paul Younger" <[EMAIL PROTECTED]> >> Subject: [Laszlo-user] Runtime Performance >> To: <[email protected]> >> Message-ID: >> <[EMAIL PROTECTED]> >> Content-Type: text/plain; charset="us-ascii" >> >> thank you, Michael. your comments are helpful. >> >> could you (or anyone else) provide some parameters for what kind of >> performance to expect from applications with varying numbers of >> views? >> what are the practical limits? and is runtime performance something >> that could be expected to improve significantly in the near future? >> >> another question, how would one expect the runtime performance of the >> flash-based ui to compare with an ajax-based approach? >> >> and one last question: do you see people sub-dividing larger apps >> into >> small pieces - separate lzx files - to speed the runtime >> performance of >> each? >> >> paul >> >> >> >> ________________________________ >> >> From: Michael Pliskin [mailto:[EMAIL PROTECTED] >> Sent: Friday, February 17, 2006 4:30 PM >> To: Paul Younger >> Cc: [email protected] >> Subject: Re[2]: [Laszlo-user] Changing a nodes parent >> >> >> >> Hello Paul, >> >> >> >> The basic problem with large applications in Laszlo is the lack of >> static compiler checks and thus the lack of easy way to perform >> refactorings. Another major caveat is its asynchronous nature >> breaking >> the traditional modality concept and requiring a very specific >> programming style, sometimes introducing a lot of spaghetti code. >> These >> two are the major ones when dealing with large application, at least >> from my experience. Another problems is that XML-based view >> replication >> is too slow for large apps, and in general lots of views can >> introduce >> the performance problems as well. >> >> >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: > http://openlaszlo.org/pipermail/laszlo-user/attachments/20060217/ > deec5720/at > tachment-0001.html >> >> ------------------------------ >> >> Message: 5 >> Date: Fri, 17 Feb 2006 16:42:50 -0800 >> From: Sarah Allen <[EMAIL PROTECTED]> >> Subject: Re: [Laszlo-user] Runtime Performance >> To: Paul Younger <[EMAIL PROTECTED]> >> Cc: [email protected] >> Message-ID: <[EMAIL PROTECTED]> >> Content-Type: text/plain; charset=windows-1252; format=flowed >> >> >> Laszlo Mail is a large application that performs well. Performance >> doesn't come for free -- that's just the reality of these >> applications, >> whether they're done with Laszlo or AJAX. The good news is that there >> are many techniques and APIs that allow you to performance-tune a >> Laszlo >> app. >> >> For example: lazy replication reduces the number of views required >> for >> displaying replicated data; initstage attribute can control when >> part of >> the application instanciate; and dynamically loaded libraries can >> defer >> download size and load time for less frequently used operations. >> There >> are also performance measurement tools: a call profiler and a size >> profiler. >> >> While Javascript certainly allows you to write spaghetti code, the >> OOP >> features of Laszlo (class tag, etc) allow us to create significantly >> better structure than what you could do with plain old Javascript. If >> you keep your app free of debugger warnings, you can see at runtime >> warnings when you have refactored incorrectly if there is anything >> the >> compiler didn't catch. >> >> Java or C++ provide a lot of features that make it comfortable for >> engineers to build large applications, expecially with new fancy >> tools >> that help with refactoring; however, in creating GUI applications LZX >> offers real flexibility throughout the process that is much more >> difficult to acheive in other languages. >> >> Hope that helps! >> >> Sarah Allen >> Director of Enginering >> Laszlo Applications Group >> >> Paul Younger wrote: >> >>> thank you, Michael. your comments are helpful. >>> >>> could you (or anyone else) provide some parameters for what kind of >>> performance to expect from applications with varying numbers of >>> views? >>> what are the practical limits? and is runtime performance something >>> that could be expected to improve significantly in the near future? >>> >>> another question, how would one expect the runtime performance of >>> the >>> flash-based ui to compare with an ajax-based approach? >>> >>> and one last question: do you see people sub-dividing larger apps >>> into >>> small pieces - separate lzx files - to speed the runtime performance >>> of each? >>> >>> paul >>> >>> -------------------------------------------------------------------- >>> ---- >>> >>> *From:* Michael Pliskin [mailto:[EMAIL PROTECTED] >>> *Sent:* Friday, February 17, 2006 4:30 PM >>> *To:* Paul Younger >>> *Cc:* [email protected] >>> *Subject:* Re[2]: [Laszlo-user] Changing a nodes parent >>> >>> Hello Paul, >>> >>> The basic problem with large applications in Laszlo is the lack of >>> static compiler checks and thus the lack of easy way to perform >>> refactorings. Another major caveat is its asynchronous nature >>> breaking >>> the traditional modality concept and requiring a very specific >>> programming style, sometimes introducing a lot of spaghetti code. >>> These two are the major ones when dealing with large application, at >>> least from my experience. Another problems is that XML-based view >>> replication is too slow for large apps, and in general lots of views >>> can introduce the performance problems as well. >>> >>> -------------------------------------------------------------------- >>> ---- >>> >>> _______________________________________________ >>> Laszlo-user mailing list >>> [email protected] >>> http://www.openlaszlo.org/mailman/listinfo/laszlo-user >>> >>> >> >> >> >> ------------------------------ >> >> _______________________________________________ >> Laszlo-user mailing list >> [email protected] >> http://www.openlaszlo.org/mailman/listinfo/laszlo-user >> >> >> End of Laszlo-user Digest, Vol 16, Issue 32 >> ******************************************* > > _______________________________________________ > Laszlo-user mailing list > [email protected] > http://www.openlaszlo.org/mailman/listinfo/laszlo-user _______________________________________________ Laszlo-user mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-user
