Martin, > 2. I’m not sure if I agree to your proposal of dispatching >> non-SequencedEvents, from the queue. The events arriving after a particular >> SequencedEvent could be dependent on this event – for example, the current >> SequencedEvent could be a focus change event, and the subsequent events >> could be Key events. So, as per your solution, if we dispatch them, there >> is a possibility that the intended component may not receive those events. >> > My understanding is that if you want hard-dependency enforcements, you > have to wrap events under SequencedEvent events. All other asynchronous > events have absolutely no guarantees. Blocking the EDT should not be done > and that's the reason why we dispatch non-SequencedEvent events in the > meanwhile. Please note that the only events that are put on hold and > re-posted lated are SequencedEvent events that, if dispatched, would > violate the sequence rule. >
I read again the patch code, and did not noticed what is causing other events go be dispatched instead of blocking. Could you explain your logic ? I jnderstand from Krishna comment that SequencedEvent induce a 'barrier' for related events... Laurent >
