Sorry, I mean "With /synchronous event dispatch/, 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."
On Wed, Dec 10, 2008 at 23:31, 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. > > Yeah, interesting thread. >
