Bug #499
closedSwing changes outside the event thread
0%
Description
When the SwingWorker class was added to Morpho to create new threads for
time-consuming tasks, some modifications to Swing components were apparently
moved outside the event thread. This is not allowed since Swing components are
not multithreaded. Problems have not been noted during normal operation of
Morpho but may cause subtle problems in the future. (Bug noted during attempts
to convert Morpho to run with Java Web Start).
In particular, there are a number of modifications made to the treenode
structure in the XML editor outside the event thread. This would not appear to
be a problem until a new DefaultTreeModel is created and a method like 'reload'
is called. According to the documentation, this method triggers the Model to
notify all listeners that the model has changed.
Updated by Matt Jones over 22 years ago
We need to be sure this is working reliably for the next release (1.2). Please
test thoroughly.
Updated by Dan Higgins about 22 years ago
10/2/02 - higgins
According to the Java tutorial,
Rule: Once a Swing component has been realized, all code that might affect or
depend on the state of that component should be executed in the
event-dispatching thread
Currently, the SwingWorker class is used in a number of locations. namely
C:\work\morpho\src\edu\ucsb\nceas\morpho\editor\DocFrame.java
fixed
C:\work\morpho\src\edu\ucsb\nceas\morpho\Morpho.java
OK
C:\work\morpho\src\edu\ucsb\nceas\morpho\query\DeleteCommand.java
morphoFrame.setBusy(true);refreshDataPackageFrame violates rule
C:\work\morpho\src\edu\ucsb\nceas\morpho\query\ExportCommand.java
morphoFrame.setBusy(true); violates rule
C:\work\morpho\src\edu\ucsb\nceas\morpho\query\LocalToNetworkCommand.java
frame.setBusy(true); violates rule
C:\work\morpho\src\edu\ucsb\nceas\morpho\query\NetworkToLocalCommand.java
frame.setBusy(true); violates rule
C:\work\morpho\src\edu\ucsb\nceas\morpho\query\OpenDialogBoxCommand.java
morphoFrame.setBusy(true); violates rule
C:\work\morpho\src\edu\ucsb\nceas\morpho\query\OpenPackageCommand.java
morphoFrame.setBusy(true); violates rule
C:\work\morpho\src\edu\ucsb\nceas\morpho\query\OpenPreviousVersionCommand.java
morphoFrame.setBusy(true); violates rule
C:\work\morpho\src\edu\ucsb\nceas\morpho\query\RefreshCommand.java
morphoFrame.setBusy(true); violates rule
C:\work\morpho\src\edu\ucsb\nceas\morpho\query\ReviseSearchCommand.java
morphoFrame.setBusy(true); violates rule
C:\work\morpho\src\edu\ucsb\nceas\morpho\query\SearchCommand.java
morphoFrame.setBusy(true); violates rule
A recurring violation of the rule appears in several places where the 'flapping
butterfly' is set with a 'setBusy' command outside the event thead. (This uses
the "ProgressIndicator" class to reset the icon used in a JComponent). No code
bugs are obviously caused by this in Morpho, but we should probably make the
setBusy operation into a thread and use 'invokeLater' to execute in the eventThread.
Updated by Dan Higgins about 22 years ago
fixed 'morphoFrame.setBusy(true)' so that the actual changing of the busy icon
is always done inside the event thread. This was done by changing the
ProgressIndicator class to implement Runnable and using involkLater in the
morphoFrame.setBusy method.
This fixes a problem in almost all the SwingWorker instances, but each still
needs to be examined for other component changes outside the event thread.
Updated by Dan Higgins about 22 years ago
All the SwingWorker instances have been examined to look for Swing component
changed outside the event thread and any such changes have been moved to the
inside of the event loop.
(Since there were no apparently problems even in code that did change Swing
components outside the event loop, it is impossible to be sure that all
instances have been fixed!)