This is a really good question and something I too grapple with. I found this helpful as it explains some of the internals of the player. Take a look at doLater(), you never know, it may help.
http://weblogs.macromedia.com/pent/archives/2005/05/dolater_vs_seti.cfm The reality is that the single threaded nature of the player means that you cannot have asynchronous processing. I too was surprised at how the dispatchEvent processing occurs, but once you start thinking in flash terms it makes sense. It isn't particularly suited to your problem, but it makes sense. I got round my issues eventually by altering the architecture of my entire application. First I broke the processing into smaller pieces by reducing the size of the transaction with my server, i.e. dealing with the data at a lower level of granularity - this was probably a good thing to do in any case. Second I put processing behind a progress dialog so at least the user was amused while they were waiting. Third I postponed the really heavy work until I had a suitable moment triggered by a user action that carried the expectation of a wait (in my case a synchronise action with the server). Using a single threaded player I found it beneficial to think more procedurally when structuring my code - back to the good old days of C. HTH Simon --- In flexcoders@yahoogroups.com, "Alex Harui" <[EMAIL PROTECTED]> wrote: > > Only one thread in flex/flash actionscript. Asynch i/o is funneled into > that thread on each frame. If you can, break heavy lifting into > segments per frame or on demand > > > > ________________________________ > > From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of danielggold > Sent: Friday, November 09, 2007 2:49 PM > To: flexcoders@yahoogroups.com > Subject: [flexcoders] Where to do heavy lifting in a Flex app? (no > threading?) > > > > I've got a few data processing functions in a Flex app I'm developing > that have to do some heavy lifting and require some time to finish > executing. I'm using cairngorm in this app, and the work is done on > the result handler of the command. I was surprised to see that this > function completely stalled the application until it finished > executing. For some reason since this was done on the result of an > event, I thought it would be executed in some background thread. I > really don't care how long it takes to process, I just want the UI to > be usable while it does its work. > > I did some more tinkering and I discovered that event handling in Flex > was not working the way I believed. When I call dispatchEvent in a > function, any functions registered as listeners to this event run to > completion before the next line of code is executed. I thought the > "event flow" in Flex would be handled in a different thread some how > so that dispatchEvent would return to the calling function immediately > and you could go on with your work, all the listeners would be > executed at some later time. > > Does anyone have any good insight about where "heavy lifting" should > be done in Flex? If everything happens serially like this it seems > like structuring a fairly large application would be tough to do. You > almost always need a place to do "background work" that is not time > critical. > > Any responses are appreciated >
