Block useraction during macro execution?

[vischer]

Hi all,

Is there a method to block user interference while a macro is running? Macro commands that work on the front window can easily be spoilt with an unintended click in the wrong window.

For example a command like this one would make life simpler when distributing macros:

blockUserInteraction(boolean)
  During macro execution, any user action that would
  activate a different image window is blocked.
  It still is possible to move a window
  via command-click in the title bar.

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

[Michael Schmid]

Hi Norbert,

as far as I can determine, macros running in BatchMode have their own
foreground image, independent of what the user selects. Try the
following macro:

   newImage("imageOne", "8-bit white", 256, 256, 1);
   newImage("imageTwo", "8-bit white", 256, 256, 1);
   setBatchMode(true);
   showStatus("Select image while BatchMode on");
     for (i=0; i<10; i++) {
     wait(1000);
     print("Macro foreground image: " + getTitle() );
   }
   print("Macro done.");

Also imageIDs for selecting images are independent of any other activity
that happens in parallel.

Nevertheless, a BatchMode macro is not immune from influences of
foreground processes, e.g.:
- Modifying/closing an input image (you may duplicate the input image(s)
at the beginning of the BatchMode phase to avoid that)
- Changing global options that affect the macro
- Some built-in commands (such as Process>Math/...) and external plugins
are not written for concurrent operation in multiple threads.  E.g.
filter parameters are often stored in static class variables, and these
variables also used for the filtering.  So, if the same function/plugin
is used interactively and by a macro at the same time, it may not work
as intended or fail with an exception.


Michael
________________________________________________________________


On 2017-02-06 17:04, Norbert Vischer wrote:

> Hi all,
>
> Is there a method to block user interference while a macro is running?
> Macro commands that work on the front window can easily be spoilt with
> an unintended click in the wrong window.
>
> For example a command like this one would make life simpler when
> distributing macros:
>
> blockUserInteraction(boolean)
>   During macro execution, any user action that would
>   activate a different image window is blocked.
>   It still is possible to move a window
>   via command-click in the title bar.
>
> Norbert
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

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

[vischer]

Thanks Michael for this useful hint, which solves my problem.

Norbert

> On 7. Feb 2017, at 17:39, Michael Schmid <[hidden email]> wrote:
>
> Hi Norbert,
>
> as far as I can determine, macros running in BatchMode have their own foreground image, independent of what the user selects. Try the following macro:
>
> newImage("imageOne", "8-bit white", 256, 256, 1);
> newImage("imageTwo", "8-bit white", 256, 256, 1);
> setBatchMode(true);
> showStatus("Select image while BatchMode on");
>   for (i=0; i<10; i++) {
>   wait(1000);
>   print("Macro foreground image: " + getTitle() );
> }
> print("Macro done.");
>
> Also imageIDs for selecting images are independent of any other activity that happens in parallel.
>
> Nevertheless, a BatchMode macro is not immune from influences of foreground processes, e.g.:
> - Modifying/closing an input image (you may duplicate the input image(s) at the beginning of the BatchMode phase to avoid that)
> - Changing global options that affect the macro
> - Some built-in commands (such as Process>Math/...) and external plugins are not written for concurrent operation in multiple threads.  E.g. filter parameters are often stored in static class variables, and these variables also used for the filtering.  So, if the same function/plugin is used interactively and by a macro at the same time, it may not work as intended or fail with an exception.
>
>
> Michael
> ________________________________________________________________
>
>
> On 2017-02-06 17:04, Norbert Vischer wrote:
>> Hi all,
>> Is there a method to block user interference while a macro is running?
>> Macro commands that work on the front window can easily be spoilt with
>> an unintended click in the wrong window.
>> For example a command like this one would make life simpler when
>> distributing macros:
>> blockUserInteraction(boolean)
>> During macro execution, any user action that would
>> activate a different image window is blocked.
>> It still is possible to move a window
>> via command-click in the title bar.
>> Norbert
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

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

[Stein Rørvik]

Interesting thread;
unfortunately I have a similar issue which is not solved by this batch mode trick.

The problem is that if a macro creates a table window, that table window (and hence the ImageJ application) is forced in front of all other applications when it is created. The main problem with that, is that whatever keypresses you are typing in that other application is passed to ImageJ, causing unintended results because of the built-in shortcuts. This may be a Java / Windows OS problem rather than an ImageJ problem, but if someone knows of any fix or workaround I would be grateful, as this prevents me from running large processing tasks in the background while working (typing) in other applications. The problem seems to be connected to specifically to table-type windows, not the regular Result window or image windows.

The following macro illustrates and explains the problem:

close("Summary");
run("Blobs (25K)");
setAutoThreshold("Default");

waitForUser("Please start another Windows application such as Notepad or Word;\n" +
"then go back to ImageJ keeping the window open and press ok.\n" +
"Then activate and try to type some text in the other application window.\n" +
"The keypresses will go to ImageJ instead of the other application,\n" +
"because the Summary table window is forced to front during macro execution.\n" +
"Activating Batch Mode does not help in this case.");

setBatchMode(true);
for (i=0; i<10; i++) {
        print("Analyze Particles:");
        run("Analyze Particles...", "display clear summarize");
        //this creates the summary table, which is forced in front of all open windows in the OS
        wait(1000);
}

Stein

-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Norbert Vischer
Sent: 10. februar 2017 11:55
To: [hidden email]
Subject: Re: Block useraction during macro execution?

Thanks Michael for this useful hint, which solves my problem.

Norbert

> On 7. Feb 2017, at 17:39, Michael Schmid <[hidden email]> wrote:
>
> Hi Norbert,
>
> as far as I can determine, macros running in BatchMode have their own foreground image, independent of what the user selects. Try the following macro:
>
> newImage("imageOne", "8-bit white", 256, 256, 1); newImage("imageTwo",
> "8-bit white", 256, 256, 1); setBatchMode(true); showStatus("Select
> image while BatchMode on");
>   for (i=0; i<10; i++) {
>   wait(1000);
>   print("Macro foreground image: " + getTitle() ); } print("Macro
> done.");
>
> Also imageIDs for selecting images are independent of any other activity that happens in parallel.
>
> Nevertheless, a BatchMode macro is not immune from influences of foreground processes, e.g.:
> - Modifying/closing an input image (you may duplicate the input
> image(s) at the beginning of the BatchMode phase to avoid that)
> - Changing global options that affect the macro
> - Some built-in commands (such as Process>Math/...) and external plugins are not written for concurrent operation in multiple threads.  E.g. filter parameters are often stored in static class variables, and these variables also used for the filtering.  So, if the same function/plugin is used interactively and by a macro at the same time, it may not work as intended or fail with an exception.
>
>
> Michael
> ________________________________________________________________
>
>
> On 2017-02-06 17:04, Norbert Vischer wrote:
>> Hi all,
>> Is there a method to block user interference while a macro is running?
>> Macro commands that work on the front window can easily be spoilt
>> with an unintended click in the wrong window.
>> For example a command like this one would make life simpler when
>> distributing macros:
>> blockUserInteraction(boolean)
>> During macro execution, any user action that would activate a
>> different image window is blocked.
>> It still is possible to move a window via command-click in the title
>> bar.
>> Norbert
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

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

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

[Wayne Rasband-2]

> On Feb 16, 2017, at 11:08 AM, Stein Rørvik <[hidden email]> wrote:
>
> Interesting thread;
> unfortunately I have a similar issue which is not solved by this batch mode trick.
>
> The problem is that if a macro creates a table window, that table window (and hence the ImageJ application) is forced in front of all other applications when it is created. The main problem with that, is that whatever keypresses you are typing in that other application is passed to ImageJ, causing unintended results because of the built-in shortcuts. This may be a Java / Windows OS problem rather than an ImageJ problem, but if someone knows of any fix or workaround I would be grateful, as this prevents me from running large processing tasks in the background while working (typing) in other applications. The problem seems to be connected to specifically to table-type windows, not the regular Result window or image windows.

The latest ImageJ daily build (1.51k17) fixes a bug that, on Windows, could cause table windows (“Results”, “Summary”, etc.) to be forced to the front of other applications when updated. Upgrade to the daily build and ImageJ should behave as expected when running in the background as long as all table windows are opened at the start of the macro and re-used.

-wayne

> The following macro illustrates and explains the problem:
>
> close("Summary");
> run("Blobs (25K)");
> setAutoThreshold("Default");
>
> waitForUser("Please start another Windows application such as Notepad or Word;\n" +
> "then go back to ImageJ keeping the window open and press ok.\n" +
> "Then activate and try to type some text in the other application window.\n" +
> "The keypresses will go to ImageJ instead of the other application,\n" +
> "because the Summary table window is forced to front during macro execution.\n" +
> "Activating Batch Mode does not help in this case.");
>
> setBatchMode(true);
> for (i=0; i<10; i++) {
> print("Analyze Particles:");
> run("Analyze Particles...", "display clear summarize");
> //this creates the summary table, which is forced in front of all open windows in the OS
> wait(1000);
> }
>
> Stein
>
> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Norbert Vischer
> Sent: 10. februar 2017 11:55
> To: [hidden email]
> Subject: Re: Block useraction during macro execution?
>
> Thanks Michael for this useful hint, which solves my problem.
>
> Norbert
>
>> On 7. Feb 2017, at 17:39, Michael Schmid <[hidden email]> wrote:
>>
>> Hi Norbert,
>>
>> as far as I can determine, macros running in BatchMode have their own foreground image, independent of what the user selects. Try the following macro:
>>
>> newImage("imageOne", "8-bit white", 256, 256, 1); newImage("imageTwo",
>> "8-bit white", 256, 256, 1); setBatchMode(true); showStatus("Select
>> image while BatchMode on");
>>  for (i=0; i<10; i++) {
>>  wait(1000);
>>  print("Macro foreground image: " + getTitle() ); } print("Macro
>> done.");
>>
>> Also imageIDs for selecting images are independent of any other activity that happens in parallel.
>>
>> Nevertheless, a BatchMode macro is not immune from influences of foreground processes, e.g.:
>> - Modifying/closing an input image (you may duplicate the input
>> image(s) at the beginning of the BatchMode phase to avoid that)
>> - Changing global options that affect the macro
>> - Some built-in commands (such as Process>Math/...) and external plugins are not written for concurrent operation in multiple threads.  E.g. filter parameters are often stored in static class variables, and these variables also used for the filtering.  So, if the same function/plugin is used interactively and by a macro at the same time, it may not work as intended or fail with an exception.
>>
>>
>> Michael
>> ________________________________________________________________
>>
>>
>> On 2017-02-06 17:04, Norbert Vischer wrote:
>>> Hi all,
>>> Is there a method to block user interference while a macro is running?
>>> Macro commands that work on the front window can easily be spoilt
>>> with an unintended click in the wrong window.
>>> For example a command like this one would make life simpler when
>>> distributing macros:
>>> blockUserInteraction(boolean)
>>> During macro execution, any user action that would activate a
>>> different image window is blocked.
>>> It still is possible to move a window via command-click in the title
>>> bar.
>>> Norbert

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