Odd behavior from Threshold

[Bob Loushin]

I am writing a plugin that needs to fit into the following workflow:

User opens image.
User runs plugin.
The plugin opens the threshold window, and waits until the user has made an adjustment and hit "Apply".
The plugin does the thresholding, then does other stuff, then ends.
User saves image, opens new one, runs plugin again....

Here's the part of the code that does the thresholding:

boolean done = false;
ThresholdAdjuster thresh = new ThresholdAdjuster();
ThreadGroup threadGroup = Thread.currentThread().getThreadGroup();
while (!done)
{
IJ.wait(1000); //Take a break between checks so as not to bog the system.
done = true;
Thread[] threads = new Thread[threadGroup.activeCount()];
threadGroup.enumerate(threads);
for (i=0; i<threads.length; i++)
if (threads[i].getName().equals("ThresholdAdjuster")) done = false;
}

The first time through, all is well. But the second time, it fails, depending on how I handle it.
1) If I close the threshold window by clicking on the x in the upper right corner of the window before I run the plugin the second time, all is well. But having to manually close this window after every run is annoying, and I'd like to eliminate this step.

2) If I leave the threshold window open while I open the second image and rerun the plugin, the threshold window is brought to the front, but the plugin does not wait for user input--it just moves on and tries to process the unthresholded image.

3) If I add a line to the plugin, after the while loop, like thresh.dispose() or thresh.setVisible(false), then the next time the plugin is run, the threshold window does not come back, and the plugin again tries to process the unthresholded image.

4) If I leave in the thresh.setVisible(false) line, and add thresh.setVisible(true) just before the while loop, the threshold window still does not come back, and the plugin again tries to process the unthresholded image.

Is there a way to do this that doesn't require the user to constantly close the Threshold window? It doesn't really matter if it is left open between runs (and waited for every time!) or is closed by the plugin, then reopened successfully (and waited for!) with each run.

Thank you!

[dscho]

Hi Bob,

On Fri, 18 Nov 2011, Bob Loushin wrote:

> I am writing a plugin that needs to fit into the following workflow:
>
> User opens image.
> User runs plugin.
> The plugin opens the threshold window, and waits until the user has made an adjustment and hit "Apply".
> The plugin does the thresholding, then does other stuff, then ends.
> User saves image, opens new one, runs plugin again....

Relying on threads' names is inherently unsafe.

Better to iterate the components in the ThreadAdjuster and put a listener
to the Apply button. But even that is suboptimal design.

The best would be to have a NonBlockingGenericDialog whose button the user
should press instead of the Apply button. That'll be always safe and does
not require any hackery.

Ciao,
Johannes

[Bob Loushin]

Hi Johannes,

Yeah, I knew it was a hack when I did it, but my experience with threads is
zero so I patched together a workaround from what I learned reading the
ThreadKiller plugin code and the API docs on Thread and ThreadGroup.  My
Java is mostly self-taught, and my background is image processing
algorithms, so when it comes to user interfaces, threads, etc., it's mostly
seat of the pants flying for me.  Wayne Rasband suggested (offline) that I
try the WaitForUserDialog class.  I'll give both ideas a try Monday and see
if I can make one of them work.  I'm a little concerned that adjusting the
threshold in one window while having to click continue in another might get
confusing for the end user (who is not me, so this introduces training
issues).  Your idea of attaching a listener to the Apply button may work for
my case.

Thank you to both of you for your suggestions.

Bob

-----Original Message-----
From: Johannes Schindelin
Sent: Friday, November 18, 2011 9:46 PM
To: Bob Loushin
Cc: [hidden email]
Subject: Re: Odd behavior from Threshold

Hi Bob,

On Fri, 18 Nov 2011, Bob Loushin wrote:

> I am writing a plugin that needs to fit into the following workflow:
>
> User opens image.
> User runs plugin.
> The plugin opens the threshold window, and waits until the user has made
> an adjustment and hit "Apply".
> The plugin does the thresholding, then does other stuff, then ends.
> User saves image, opens new one, runs plugin again....

Relying on threads' names is inherently unsafe.

Better to iterate the components in the ThreadAdjuster and put a listener
to the Apply button. But even that is suboptimal design.

The best would be to have a NonBlockingGenericDialog whose button the user
should press instead of the Apply button. That'll be always safe and does
not require any hackery.

Ciao,
Johannes