> I thought that updating the UI also on the MDR event thread guarantees a > stable model while updating the UI. But it doesn't guarantee a stable UI. If the MDR thread is changing the UI the user can be interacting with that UI at the same time and typically cause problems when the AWT thread paints. That is what causes problems and what is happening in the sequence diagrams.
With the sequence diagram example releasing of the mouse after drawing a message results in far more restructuring of Figs then most other edges. When that is complete the AWT thread will paint and so the Figs will iterate through their paint methods as the AWT thread calls them. All of that happens on the AWT thread. But also a change to the model is made when the mouse is released. When that event is received it also results in a need to change the Fig structure. So there is some chance that the AWT thread will be trying to change the Fig structure at the same time as the MDR thread. In fact in my case that's not true but just by chance that the race condition works that way. The AWT thread is typically painting the Fig (iterating through its child paint methods) at the same time as the MDR thread is trying to change its composition of child Figs. I'm wondering if I might be able to get around this by filtering out some of the MDR events. But in principle, if you want to update the UI from the MDR thread then it is safer to use invokeLater to push the responsibility to AWT. What I'm trying to suggest is a way to isolate where its necessary to do this in as few places as possible and so have it clear to the developer where UI and none UI code without having to worry. It seems to me that the best time is as soon as we've received the event. Bob. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
