I'd have to agree with Seth, though I would suggest using a timer, as the setInterval function appears to be deprecated.
In the past I've actually written a light weight class that encapsulated the timer logic and handled storing state between function calls. -- Josh Vanderberg vanderblog.typepad.com - Flex blog and open source flex components --- In flexcoders@yahoogroups.com, "Aldo Bucchi" <[EMAIL PROTECTED]> wrote: > > Hi Guys, > > I need to run an expensive computation in the background ( 2 seconds > on a modern day laptop ) while keeping the UI responsive. For this > matter I have tried creating a secondary application and communicate > with it in a non-blocking way. I share my thoughts so far to see if > anyone can help with this one. > > First, some approaches to create a secondary application: > * Load a module at runtime > * Publish a module from within a new Frame ( Gonzalez/Harui trick ) > * Open another SWF altogether ( seems the safest best bet to me ) > > Some approaches to communicate between apps: > * LocalConnection ( sync ) > * Write/Poll a LSO ( async ) > > And to go from blocking to non-blocking communication ( maybe ) > * Upon receiving a call start a timer and listen for the completion > event. This should make the call return while leaving it up to events > to start the real processing. > > Now, I haven't tried every combination yet, but so far I found some > interesting results: > > I created two separate applications that talk through a > LocalConnection. They use the timer trick ( upon receiving a call they > set up a very short internal timer that will eventually start internal > execution of the code ). If I open both SWFs in IE they effectively > work as expected. I can start a very heavy computation on the > secondary app while the first remains totally responsive to user > events. Then I can make a reverse call and pass the results back. So > far so good :) > > Firefox, however, is a show killer. No matter how I open the two apps > ( tabs, apps, etc ) blocking occurs. > > Can someone from the flash player shed some light on this? > This is not real multi-threading, it is simpler in the sense that I > don't need synchronization. The contract is passing an input and > waiting for a result. > > Now, even if I managed to pull this off with parallel applications... > how would I materialize that setup in AIR? > > Thanks, > Aldo > > > > -- > :::: Aldo Bucchi :::: > +1 858 539 6986 > +56 9 8429 8300 > +56 9 7623 8653 > skype:aldo.bucchi >
