Posted by
Michael Schmid on
URL: http://imagej.273.s1.nabble.com/Copy-To-System-and-asynchronicity-tp5023888p5023894.html
Hi Fred,
concerning:
> I have noticed that the processing of the screen rendering of the
> GenericDialog, specifically the removal thereof from the screen,
> and the return of the showDialog method are asynchronous of each
> other. Is there a way to make sure the GenericDialog window has
> been removed from the screen?
It is a property of Java that changes to the GUI on the screen are
asynchronous; it is rather difficult to avoid this in ImageJ. There is
such code for images brought into the foreground, but it has been the
root for many problems (that are solved by now, as far as I can say). If
possible at all, it would be a pain to implement something like this for
the GenericDialog.
For your application of capturing the screen, the easiest would be a
short delay (which is not a very clean way of doing it).
If you have a NonblockingGenericDialog (which you can get for most
filters, enable it in the Misc options), you could try to explicitly put
the image window into the foreground with IJ.selectWindow(imageID). This
should wait until the image is really there. I did not try it however,
and I fear that it would not work for 'normal' (non-blocking)
GenericDialogs.
Instead of the screenshot, you might also try Plugins>Utilities>Capture
Image.
-----
Concerning the 'copy to system' race condition, I can confirm it.
Javascript code:
impB = IJ.openImage("
https://imagej.net/images/blobs.gif");
impB.show();
Thread.sleep(1000);
impP = IJ.openImage("
https://imagej.net/images/particles.gif");
impP.show();
Thread.sleep(1000);
IJ.run("Copy to System", ""); //should copy the particles
IJ.selectWindow(impB.getID());
Thread.sleep(1000);
IJ.run("System Clipboard", ""); //shows the blobs, not the particles
Michael
________________________________________________________________
On 30.08.20 05:38, Fred Damen wrote:
> Greeting Wayne,
>
> An annoyance/bug and a question.
>
> With a ImageWindow current/active and the Edit>Copy to System is invoked
> and then no other ImageJ window becomes active the contents of the
> aforementioned ImageWindow gets placed into the system clipboard. If
> another ImageJ window gets activated, i.e., made current, a short time
> later (as dictated by current system conditions and possible OS
> peculiarities) the newly current window is what is put on the system
> clipboard. As these are asynchronous method calls, the current
> ImageWindow can, and in my case does, change in between
> ij.plugin.Clipboard.scopy calling system Clipboard.setContents and the
> system Clipboard calling ij.plugin.Clipboard.getTransferData, n.b.
> getTransfterData refetches the current window. Caching the image before
> the call to setContents and use thereof in getTransferData should rectify
> this issue.
>
> I have noticed that the processing of the screen rendering of the
> GenericDialog, specifically the removal thereof from the screen, and the
> return of the showDialog method are asynchronous of each other. Is there
> a way to make sure the GenericDialog window has been removed from the
> screen? I have written a method that resizes and raises an ImageJ
> image/nonimage window and then using Robot to take a snapshot of this
> window, OS adornments included; although about half the time the
> GenericDialog has not yet been removed from the screen and is covering
> window, thus corrupting the snapshot. I have tried putting waits in, but
> to no avail. I suspect that the thread that was displaying the
> GenericDialog is being blocked by the thread that had called the
> showDialog, n.b., OS is Fedora 31.
>
> Thanks in advance,
>
> Fred
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html