intermittent problem with NonBlockingGenericDialog

[Kenneth Sloan-2]

I am in the wonderful position of having to deal with an INTERMITTENT problem.  Even worse,
the problem seems to occur more frequently on one of my "client" machines - but not so much on my development machine.

Both are 2019 macBook Pro laptops, running the latest Mac OSX and ImageJ 1.52r.

The problem is that *sometimes* (my client reports "roughly every second time") when a dialog box is displayed, it is not possible to edit any of the fields.  Nothing is highlighted, and clicking on the window has no effect (I think).  

The good news is that most of the time, he wants to accept the (remembered in Preferences) previously set values, and merely needs to hit Enter - and all is well.

So...I'm unlikely to spend a LOT of time worrying about this, but I thought I would report it just in case it rings any bells with anyone else.

Has anyone else seen this kind of problem?

Does anyone know what the cause might be?

For context, the relevant plugin displays an image, asks you to select a rectangular region, and then displays a NonBlockingGenericDialog with many parameters (some numbers, some text, one checkbox).  The symptom is that *sometimes* none of the fields are highlighted, and nothing seems to be able to change that.  The dialog can be *accepted* - but not updated.

I'm stumped.

--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Fred Damen]

Greetings Kenneth,

I see two issues here. The NonBlockingGenericDialog, by way of
GenericDialog being its super class, insists on setting one on the
ImageWindow(s) as the GUI parent. This causes this ImageWindow to be
raised, in my case at least, and possibly other things in your case.  I
suspect that this is the source of the intermittency of your issue. It
would be nice if NonBlockingGeneriDialog had a constructor that takes a
Frame and passes it to the GenericDialog super class as the intended
parent.  In my case setting the parent to IJ.instance would alleviate my
issue.

From your functional description I assume that your widgets are being
disabled (which should appear as greyed out), but from you visual
description (not highlighted) it would seem that they are not receiving
focus.  This may be useful distinction when trying to debug this issue.  I
do not experience what you describe, although I suspect it is specific to
the OS/GUI.

What I have done to avoid this annoyance is to create a benign ImageWindow
and have that window current when I start up my NonBlockingGenericDialog.

Fred

On Mon, June 15, 2020 12:10 pm, Kenneth Sloan wrote:

> I am in the wonderful position of having to deal with an INTERMITTENT
> problem.  Even worse,
> the problem seems to occur more frequently on one of my "client" machines
> - but not so much on my development machine.
>
> Both are 2019 macBook Pro laptops, running the latest Mac OSX and ImageJ
> 1.52r.
>
> The problem is that *sometimes* (my client reports "roughly every second
> time") when a dialog box is displayed, it is not possible to edit any of
> the fields.  Nothing is highlighted, and clicking on the window has no
> effect (I think).
>
> The good news is that most of the time, he wants to accept the (remembered
> in Preferences) previously set values, and merely needs to hit Enter - and
> all is well.
>
> So...I'm unlikely to spend a LOT of time worrying about this, but I
> thought I would report it just in case it rings any bells with anyone
> else.
>
> Has anyone else seen this kind of problem?
>
> Does anyone know what the cause might be?
>
> For context, the relevant plugin displays an image, asks you to select a
> rectangular region, and then displays a NonBlockingGenericDialog with many
> parameters (some numbers, some text, one checkbox).  The symptom is that
> *sometimes* none of the fields are highlighted, and nothing seems to be
> able to change that.  The dialog can be *accepted* - but not updated.
>
> I'm stumped.
>
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Wayne Rasband-2]

> On Jun 15, 2020, at 4:03 PM, Fred Damen <[hidden email]> wrote:
>
> Greetings Kenneth,
>
> I see two issues here. The NonBlockingGenericDialog, by way of
> GenericDialog being its super class, insists on setting one on the
> ImageWindow(s) as the GUI parent.

The NonBlockingGenericDialog class in the ImageJ 1.53c42 daily build has a

    NonBlockingGenericDialog(String title, Frame parent)

constructor.

-wayne

> This causes this ImageWindow to be
> raised, in my case at least, and possibly other things in your case.  I
> suspect that this is the source of the intermittency of your issue. It
> would be nice if NonBlockingGeneriDialog had a constructor that takes a
> Frame and passes it to the GenericDialog super class as the intended
> parent.  In my case setting the parent to IJ.instance would alleviate my
> issue.
>
> From your functional description I assume that your widgets are being
> disabled (which should appear as greyed out), but from you visual
> description (not highlighted) it would seem that they are not receiving
> focus.  This may be useful distinction when trying to debug this issue.  I
> do not experience what you describe, although I suspect it is specific to
> the OS/GUI.
>
> What I have done to avoid this annoyance is to create a benign ImageWindow
> and have that window current when I start up my NonBlockingGenericDialog.
>
> Fred
>
> On Mon, June 15, 2020 12:10 pm, Kenneth Sloan wrote:
>> I am in the wonderful position of having to deal with an INTERMITTENT
>> problem.  Even worse,
>> the problem seems to occur more frequently on one of my "client" machines
>> - but not so much on my development machine.
>>
>> Both are 2019 macBook Pro laptops, running the latest Mac OSX and ImageJ
>> 1.52r.
>>
>> The problem is that *sometimes* (my client reports "roughly every second
>> time") when a dialog box is displayed, it is not possible to edit any of
>> the fields.  Nothing is highlighted, and clicking on the window has no
>> effect (I think).
>>
>> The good news is that most of the time, he wants to accept the (remembered
>> in Preferences) previously set values, and merely needs to hit Enter - and
>> all is well.
>>
>> So...I'm unlikely to spend a LOT of time worrying about this, but I
>> thought I would report it just in case it rings any bells with anyone
>> else.
>>
>> Has anyone else seen this kind of problem?
>>
>> Does anyone know what the cause might be?
>>
>> For context, the relevant plugin displays an image, asks you to select a
>> rectangular region, and then displays a NonBlockingGenericDialog with many
>> parameters (some numbers, some text, one checkbox).  The symptom is that
>> *sometimes* none of the fields are highlighted, and nothing seems to be
>> able to change that.  The dialog can be *accepted* - but not updated.
>>
>> I'm stumped.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kenneth Sloan-2]

Hmmm...   when creating the dialog, (blocking or non-blocking) there is no provision to specify the ImageWindow to be used as the parent.

I my plugin, the immediately preceding action is to select a rectangular area.  I do this by

IJ.setTool("rectangle")

and then use WaitForUserDialog to instruct the user to select a rectangle.  The user creates the rectangle and dismisses the WFUD.

The very next thing is the creation of the NBGD listing a bunch of parameters that he can set (some of these have defaults that may depend on the dimensions of the rectangle).

My point is: the same windows should be active (that is - the relevant Image) when the dialog is created.  But, the result differs from time to time.

Most of the time (I think virtually *all* of the time that *I* have tested it) the dialog works perfectly.  It comes up with the first data field highlighted, and all fields are editable).  SOME of the time (up to 50%, according to my client) the dialog appears with no fields highlighted, and none of the fields can be selected or edited.  The dialog can be accepted.

Check that...further testing reveals that the plugin works fine if it is invoked with no open images.  
If you run it again (without closing the original image), it fails.  So....is the GenericDialog code being confused by the presence of other open ImageWindows?

Further testing - the dialog contains several NumericFields, a "Choice" field, a Checkbox, and the Cancel and OK boxes.  When it fails, the NumericFields cannot be highlighted or edited, but the Choice field works (the pulldown menu appears and can be changed) and the Checkbox can be checked.  Both the Cancel and OK boxes work.  The only failure is in the NumericFields!

I have made the plugin available on my ImageJ update site, if anyone wants to point and giggle at my code and tell me what I've done wrong. "CreativeComputation" + Area_Fraction_macOSX.jar.  All the  .java files are in the .jar.  Ignore the "macOSX" - it's just documentation of where it was BUILT - it works everywhere.  In fact, it works perfectly on a WinDoze machine, but fails (sometimes - apparently when other ImageWindows are present) on a Mac.

For now, I'm going to pursue the advice: "close all open windows before running Area_Fraction" and see how that goes.  I welcome comments on any aspect of my .java code - especially those that tell me how to avoid this problem.  [well...I could be fascist and close all open ImageWindows as my first action - but that seems draconian]

--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kenneth Sloan-2]

Wayne-

Thanks - I think you may have fixed it while I was typing my last e-mail.

I'll give it a try.

--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kenneth Sloan-2]

For those motivated to look at Area_Fraction, some fine points:

a) it will show up as Plugins>Stereology>Area Fraction
b) it will ask for a "choices" file.  You can Cancel this and it will use a default set.
c) it will ask for an image file.  Any image should work.
d) once past the parameter setting, proceed according to the pop-up guide
e) if you run it to completion, it will write a file to the directory containing the image file.
    (so...a sandbox would be good)

Finally...when I change the code to pass a parent Frame to NonBlockingGenericDialog(message, parent) - what do you recommend?  In all similar instances I have gotten away with passing null.

--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Fred Damen]

Greetings,

For GenericDialog the constructor without a requested parent, if no
ImageWindows are open then the IJ.getInstance() returned value is used. If
a null is passed in as the suggested parent then a Frame is created as the
parent, albeit, the guiScale then does not scale the GUI(s).

Fred


On Mon, June 15, 2020 4:58 pm, Kenneth Sloan wrote:

> For those motivated to look at Area_Fraction, some fine points:
>
> a) it will show up as Plugins>Stereology>Area Fraction
> b) it will ask for a "choices" file.  You can Cancel this and it will use
> a default set.
> c) it will ask for an image file.  Any image should work.
> d) once past the parameter setting, proceed according to the pop-up guide
> e) if you run it to completion, it will write a file to the directory
> containing the image file.
>     (so...a sandbox would be good)
>
> Finally...when I change the code to pass a parent Frame to
> NonBlockingGenericDialog(message, parent) - what do you recommend?  In all
> similar instances I have gotten away with passing null.
>
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html