2011/2/2 Michael Schmid <
[hidden email]>:
> Hi everyone,
>
> a strange and annoying problem:
>
> I have written a PlugInFrame that displays a grid on an image as an overlay.
> It should close when the image is closed. It works well on Mac OS X 10.4
> (Java 1.5.0_19), but on Mac OS X 10.5.8 (Java 1.5.0_26) quite often ImageJ
> becomes irresponsive on closing the image (sometimes, there was no problem,
> and in a rare cases it also happened that ImageJ did not hang after closing
> the PlugInFrame, it was hanging after closing another image later.)
>
> Using debug messages to the console I found out that setVisible(false)
> causes the EventQueue first to go to a waiting state with timeout, then it
> gets blocked forever (waiting for getting into a synchronized block
> somewhere).
> ImageJ version 1.44n.
>
> Here is the relevant code:
>
> public class Grid_Measurement extends PlugInFrame implements ImageListener,
> ...
> (many more listeners for the GUI of the panel, with buttons,
> textfields, etc.)
>
> public void imageClosed(ImagePlus imp) {
> if (imp==this.imp) close(); //close PlugInFrame when image gets
> closed
> }
>
> public void close() {
> ImagePlus.removeImageListener(this);
> ... remove the other listeners referring to the ImageCanvas
> ... I don't remove the listeners for the buttons, textfields etc.
> (too many)
> imp.setOverlay(null);
> #debug message (System.err.println) shows:
> # - the current thread is "Close", priority 4 (not the
> EventQueue)
> # - AWT-EventQueue-0 is in state RUNNABLE
> setVisible(false);
> #debug message shows now: AWT-EventQueue-0 is in state
> TIMED_WAITING
> IJ.wait(2000); //see whether we can get out after a while
> #debug message shows now: AWT-EventQueue-0 is in state BLOCKED
> dispose();
> #debug messages from here on don't display (dispose never gets
> finished).
>
>
> Does anyone have experience with such a situation?
> Any ideas what the EventQueue could be waiting for after setVisible(false)?
> Is there a way to debug it (maybe without too steep a learning curve for
> handling a debugger)?
You could try running the dispose on a separate run of the dispatch thread.
For example, wrap the dispose() call with:
SwingUtilities.invokeLater(new Runnable() { public void run() { dispose(); }});
Even though close() is called within the event dispatch thread, likely
the above will likely prevent the locking. Don't ask me why, it's
empirical.
Albert
--
http://albert.rierol.net
Locked
