IMHO, Once you get the runtime error dialog, all further behavior is undefined. Your code has finished executing and the player is no longer executing its standard workflow.
Alex Harui Flex SDK Developer Adobe Systems Inc.<http://www.adobe.com/> Blog: http://blogs.adobe.com/aharui From: [email protected] [mailto:[email protected]] On Behalf Of litlboyblue Sent: Wednesday, September 16, 2009 10:34 PM To: [email protected] Subject: [flexcoders] Re: Race conditions when event handlers triggered from different targets --- In [email protected], Gordon Smith <gosm...@...> wrote: >>>>> Yes, that is what Alex is saying. Handler B will not begin before handler A finishes. Event handlers don't get paused. Furthermore, when you (or the Player) calls dispatchEvent(), all the event handlers listening for that event execute before dispatchEvent() returns. >>>>> I really want to believe this assertion, and I hate to belabor the point, but I'm troubled by the observed behavior in the Debug Player under IE8. In this case, a run-time error was thrown by the handler of a network event and the standard dialog was displayed. This condition exposed a problem in our network message parser, which caused subsequent network events to also display run-time errors. I was unsettled to find that a new dialog was displayed, and a new Window! s OS-level thread created with each run-time error, even though I hadn't dismissed the initial error dialog. It appeared that the network event handler code executed and threw a run-time exception with each message received from the network, regardless. This would seem to be an exception to the behavior stated above; does a run-time error dialog cause the execution context to pause and allow other event handlers to be executed? If so, is this only possible in the Debug Player, or do we have to worry about protecting against possible re-entrance in handlers that access global data?
