There is a thread earlier in this mailing list, about async, non-blocking array functions. The thread is called "Request for code review: noodles - Async/non-blocking/CPS versions of the higher order functions on `Array.prototype`" - http://www.mail-archive.com/[email protected]/msg00817.html
I think this might be interesting to you, as this would provide a way to do a forEach() on your files but still being non-blocking for the UI. The speed disadvantage of setTimeout() for each item has a solution in this thread. Best regards Björn On Sat, Feb 12, 2011 at 11:58 AM, Julian Turner <[email protected]> wrote: > Hello > > I am interested in finding out how others have handled the following > problem (if indeed it has ever been an issue). > > Some background: > > I have been using JavaScript to create a number of desktop > applications. For instance, running JavaScript with > Scripting.FileSystemObject (needs to be in an ".hta" file for this) or > with FireFox XPCOM file handling components, I have been able to make > a file and folder synchroniser (compares folder trees and looks for > differences) that needs effectively no installation (given that the > necessary executables are already pre-installed as part of Windows / > Firefox etc). > > However, running a file and folder synchronisation can take a long > time, so I felt the application needed some form of "progress dialog" > which could display a progress bar and also more detailed progress > messages. > > However, I understand that browsers do not update their display until > they return from the javascript function, so what to do? > > Iframe : NO-GO > > I first tried an Iframe. Unfortunately I understand it runs in the > same "thread" effectively as the parent window (at least for IE), so > it waits as well. > > setTimeout : GO-BUT SLOW AND COMPLEX > > The next solution was to use a "continuation" style of programming, > with setTimeout; which seemed to be the most common solution on a > search. > > This involves carrying out each iteration of the function in a > timeout, and then calling setTimeout again, with the current state. > The display then updates between timeouts. > > I found this complex to implement, and too slow for my requirements. > > window.open : GO-BUT HEAVY > > The third option was to open a new browser window with window.open. > > This was a viable solution, as new browser windows appear to run in a > separate "thread". > > The only thing that let it down was that window.open is slow-ish, as > it has to open a full new browser instance with all the chrome, it is > more difficult to pass arguments, and it appears as a new stand-alone > window in the task bar, so it feels a little separate from the > application. > > window.showModelessDialog : GO - PERFECT > > This proved to be the best solution. > > The window opens quickly, it runs in a separate "thread", you have > full control over the chrome, you can easily pass arguments, and it > acts like a "child" window of the main application (not appearing in > the task bar). > > With this I have been able to create very useful progress dialog > boxes. > > However, it is IE only; and I noted with a little sadness that HTML5 > has only opted for its sister function "showModalDialog". This seems > to be a missed opportunity (although no doubt for good security > reasons), as I can see that future JS applications may have need of a > lightweight modeless child window IMHO. > > Does anyone else have any thoughts on this? > > Julian > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected] > -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
