Posted by
Bob Loushin on
Nov 19, 2011; 9:36pm
URL: http://imagej.273.s1.nabble.com/Odd-behavior-from-Threshold-tp3682526p3682528.html
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