--- In flexcoders@yahoogroups.com, "Paul Andrews" <[EMAIL PROTECTED]> wrote: > > > ----- Original Message ----- > From: "Ralf Bokelberg" <[EMAIL PROTECTED]> > To: <flexcoders@yahoogroups.com> > Sent: Tuesday, December 09, 2008 3:00 PM > Subject: Re: [flexcoders] Re: Parsley MVC :: some thoughts > > > > Hi Amy > > > > Afaik this is not possible in Flashplayer. A block of code is always > > running through without any interuption. > > I think this has been part of the discussion in the thread. While it is what > I would expect, if dispatching events causes all listening event handlers to > be called synchronously, it means that any block of code dispatching an > event is going to be interrupted and potentially "unknown" event listeners > called during the execution of that code block. > > Here's an interesting scenario: > > If I have a block of code building a data structure and it has an object > reference to some model. It could be that it encounters some situation and > dispatches an event. The event handler may then interrogate the model, > modify the model and control then returns to the executing block which is > then unaware of the model change and still iterating through the model. > > My expectation would be that dispatch event would add the event to a queue > of events ready to be handled, but those would not be handled until the code > block had completed. > > In other systems/languages my code blocks would include semaphore handling > to protect such data structures, but there's no option for me to do that in > actionscript. > > You may argue that the developer should 'know' what may potentially happen > when writing code and despatching events, but in practice who knows who may > add a new event handler to the application in future and may introduce a > problem. > > I don't have a problem with all event handlers being called when an event is > fully despatched, but that's potentially dangerous if it's done in the > middle of a code block. Anyway it's just a thing to keep in mind. I would > agree that it's a marginal and unlikely scenario.
Right, I went back and looked at the code and found that the code was calling dispatchEvent. And then at some point in the code block after that (not at the next line, but maybe 2-3 lines later), execution would go off to somewhere else that wasn't going to work before the other code ran after dispatchEvent.