The only way for a listener to not get called synchronously is if it is specifically setup to do that. For example in Flex you can call a method using callLater which will call it on the next frame. If you are not using Flex you can do the same thing by creating a timer with a duration of 1 and calling the method within the timer's handler. If you look through the Flex code you will see a lot of use of callLater as it works great for allowing data to update before you act upon it.
On Wed, Dec 10, 2008 at 8:12 AM, Amy <[EMAIL PROTECTED]> wrote: > --- In flexcoders@yahoogroups.com, "Jules Suggate" > <[EMAIL PROTECTED]> wrote: > > > > > For several years before using flash I used a proprietary GUI OO > tool that > > > had a similar (though less sophisticated) event mechanism. In > that system > > > event dispatch did not actually take place until the code block > had > > > completed - only then would handlers be invoked. This was > particularly > > > important since the system also supported database access and > transaction > > > handling so it's particularly important to have discrete units of > work that > > > form part of a transaction without interruption. So I don't think > that the > > > synchronous event despatch mechanism is as obvious as it appears > to some and > > > I think it should really be a delayed propogation. > > > > I agree. For me at least, this was completely non-obvious and now > that > > I know, feels plain bizarre. > > > > If asked before this thread, I would have answered that > > dispatchEvent() returned instantly and event handlers were invoked > > "some other time" such as after the current code block, or during > the > > Player render cycle (but that would mean event handlers always > > executed in the next frame, perhaps causing problems with > animations). > > That would give an implicit atomicity around the currently executing > > code and allow the VM to do smart things like rolling up multiple > > events of the same type within a given code block (or frame) into a > > single invokation of each listening handler. This way, triggering an > > event 100 times will mean the listeners get invoked 100 times, even > if > > the last invokation completely overwrites the work of the previous > 99. > > That's what I would have thought, too, considering how obsessive the > Flex team seems to be about optimizing. This was especially hard to > debug in my case because the listener wasn't called immediately. I > wonder if that's because it was in a different class...? > > -Amy > > > ------------------------------------ > > -- > Flexcoders Mailing List > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > Alternative FAQ location: > https://share.acrobat.com/adc/document.do?docid=942dbdc8-e469-446f-b4cf-1e62079f6847 > Search Archives: > http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups > Links > > > >
