NOTE: Forgive me for replying twice. The "Rich-Text Editor (Beta)" seems to not be posting my replies, only the ">" content. -Nick
- - - Hi Ralf - thanks for the help figuring out and thinking about this problem - About your diagram, I am getting an exception in line 4 which caused unrolling up to line 3 which unexpectedly starts dispatching more events of types >not< dispatched in line 3. Yeah so I agree, all handlers registered to listen to a particular event type on a given object instance should be called when an event of that type is dispatched from that object. I also agree there should be no unexpected interruption of my single thread. And that if I synchronously dispatch an event then that will be handled by all listeners synchronously one after the other. But my understanding about asynchronous events (like new socket data, or Timer callbacks) is that they are delivered so they enter at the top of the execution stack, being passed to all registered event handlers synchronously one after the other. The problem is what I'm seeing is unexpected calls in the middle of my stack. Check this out: I'm handling an event of one type ProgressEvent.SOCKET_DATA and I need to do some dispatching of my own, a custom "NavigationEvent" event. The dispatcher correctly delivers my NavigationEvent synchronously while I wait blocked on that dispatch. But then I am surprised as the dispatcher takes the opportunity I've given it to dispatch not only my event but it starts to deliver other events: more ProgressEvent.SOCKET_DATA's that have queued up and other queued events. The socket data ProgressEvent is recursively delivered to my 'onSocketData', recursively because this new socket data event is delivered while I'm handling the prior socket data ProgressEvent listening 'onSocketData', in the same call stack, and it causes havoc. I wasn't expecting my synchronous call to the dispatcher to dispatch events other than the one I asked it to dispatch. "Do what I say, not what you're doing." is what I am saying to myself as I see this. Diagrams do rock so I tweaked your illustration to match my situation: 1 OS dispatches event A 2 I handle event A .. there may be a Function.call higher in the stack .. 3 I dispatch event B synchronously 4 I handle event B deeper in this stack 5 I handle event B in my other registered listener after returning from 4 .. I throw a null pointer exception .. 6 I am unexpectedly handling event C after returning from 5. Then I crash. The dispatcher at 3 just dispatched C unexpectedly. I never return from my synchronous call to the dispatcher to the next line of code after "3" was called...also all of the code in 4-7 is in the same call stack started at 1. This event C is unexpected. I didn't dispatch it in 3, the OS/Adobe EventDispatcher did. I think the OS should have waited until I returned from my "A" handler entry point 2 before it dispatched C. To me that "gotta send 'em all right now" behavior is unusual. So, are you saying that it is in fact usual for C events to be dispatched at any opportunity I give the event dispatcher to dispatch events? And consequentially that I'm in store for inspection / tweaking to my event listener entry points, making them guard against recursive calls? My weekend will turn dark and gloomy if so. Or is there really a bug in the EventDispatcher code..? I'm suspicious of the Function.call() code as I've only seen this "dispatch all pending" behavior deeper in the stack after one of those is higher in the stack, as yet. Either way I think my weekend is gonna be gloomy. Or...? Danke, thanks again for the assistance, Nick San Francisco, CA USA -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
