Posted by
Fred Damen on
URL: http://imagej.273.s1.nabble.com/Copy-To-System-and-asynchronicity-tp5023888.html
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