Hi All,
How do we deal with this?
If GEF doesn't provide any synchronization, callers need to use
Swing.invokeLater() to get drawing operations queued for processing on the
Swing event thread if they aren't already running there.
Tom
The Figs are listening to model changes, and receive a lot of them.
The modelChanged() function on the Figs either dissects the
ModelChangeEvent, or reads the new model structure directly from the model.
(The former is rarely done, and difficult. The latter is common practice,
and easy, since this code is needed anyhow at load-time.)
Then, the Figs are redrawn, mostly by functions like updateAbstract() or
updateNameText(), in the way that Bob described. Often, there is just a
renderingChanged() function for a Fig.
(1). There is a lot of code involved for dissecting the ModelChangeEvents
and refreshing the exact part of the Figs that were changed, without
querying the model again - which would be the agreed ideal way to do this.
E.g. if the type of a parameter of an operation of a class is changing
name, then we have to refresh only one line of text, i.e. the operation.
Same goes for the code to update the set of model-listeners. If you do not
believe this is difficult, I dare you to write the
StateBodyNotation.updateListener() function!
(2). And since Figs are also reloaded after save, we need the functionality
to query the model anyhow... E.g. we draw the complete class by querying the
model, i.e. name, stereotypes, attribs, operations, parameters, etc, by
building the whole FigClass from scratch, when a project is loaded.
Idem for setting the model listeners.
Hence, how about a way to save us from writing/maintaining all this code
under (1), and stick solely to the way of (2), while solving the Swing
thread problem?
My proposal:
We could have the FigClass listen to ALL modelevents that may cause a change
to its appearance (and not the compartment contents). Arrival of each such
event shall set a flag, and (if it is not already started) start a task with
Swing.invokeLater().
Any next event that arrives before the task has been executed, shall have no
consequence.
When the FigClass is removeFromDiagram()'ed, the flag may be cleared, which
causes the task to do nothing.
All the above on the the MDR event processing thread.
And, on the Swing/AWT event processing thread, when the task fires, it first
clears the flag, and then refreshes/redraws the whole class at once, by
querying the model.
Why is this good:
Usually, changes come in packs - e.g. MoveUp of an Operation changes 2
operations by remove, add. Many model events only lead to redraw once.
Unless you may have a multicore uP, in which case an (probably one) extra
redraw does not do any harm anyhow. We can even build in a 100ms delay, if
that would help.
Regards,
Michiel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
