Hi Tom,
Your statement confirms it for me:
* The default implementation just removes all listeners, and then
* re-initialises completely - this is method 1.
Unless this is done atomically, while locking the MDR event thread
from delivering any events, there is no guarantee that events won't be
"lost," or, more specifically, delivered while the intended
listener(s) aren't registered. I'm pretty sure there are no
facilities to do this today, so this isn't happening and events are
getting lost (unless everything is being done on the MDR event thread
in which case there will be an implicit lock).
Hence, executing method 1, i.e. the removing of all listeners, and the
querying of the model to re-initialise the listeners, SHALL be completely
done on the MDR event thread to prevent events to be lost. This requirement
is clear now.
But I do not understand how the change done for issue 5007 solves anything.
I thought that updating the UI also on the MDR event thread guarantees a
stable model while updating the UI.
Postponing the UI update may cause disastrous effect when the model changes
somewhat more before it happens.
Regards,
Michiel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
