On 27 July 2011 08:48, david.herv...@gmail.com <david.herv...@gmail.com> wrote: > Even if multithreaded my implementation is (normally) done. > I really don't know why they have used such a mecanism... > There may be a use case I'm missing > > On 27 juil, 17:28, Sixin Zhang <sixin.zh...@gmail.com> wrote: >> i feel alike, all new registrations are delayed until the end of >> firing (depth=0) .. so nothing will happen if firing those new events >> before the end .. >> depth behaves like a lock for concurrency, but not really necessary >> for single-thread JavaScript ..
I'd like to add my "+1" ... I just finished a major debugging session. Everything was working correctly but the event handlers were not receiving the event they had signed up for. Because of firingDepth (which was >0 because of a PlaceChange event). It's really insidious because all code is correct and working in the right order and context ... but the event handlers don't respond to events. I would think that either both handler registration *and* event firing is deferred or neither. The current situation seems a strange combination where event handler registration is deferred but event firing is not. I'm wondering now whether I should implement my own EventBus (using David's patch e.g.) or if I am simply using events incorrectly? -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
