Key Pressed and moving an Roi around in a ImageWindow

[Fred Damen]

Greetings,

A while back I asked why sometimes hitting the up or down arrows in an
ImageWindow would cause the contained Roi to move up and down, and
sometimes the ImageWindow would zoom up(+) or down(-).  It turns out that
the ImageJ.keyPressed method is a low level I/O method, and as such, gets
called on every key pressed, including modifiers.
ImageJ.keyPressed/keyReleased stores the current state of the modifier
keys.  Unfortunately, if a modifier key is pressed in a ImageJ window and
then released while not in a ImageJ window, the current modifier status
may not reflect the actual current status. In my case, if the control or
shift key is pressed while in an ImageJ window and released outside and
ImageJ window, then upon hitting the up or down arrows in a ImageWindow
the zoom cmd would be run instead of the roi.nudge method being called.

Previously, I had noticed that requesting a image to be duplicated, and
then canceling, cleared this anomaly. It turns out that all you have to do
is, within the ImageWindow press and release the shift, and then the
control, keys to clear this anomaly.  It seems obvious now, but it stumped
me for a long time; so hopefully knowing this will help others.

I suspect, but have not tested, that calling KeyEvent.isShiftDown and
KeyEvent.isControlDown methods instead of IJ.shiftKeyDown() and
IJ.controlKeyDown may alleviate this issue.

Thanks,

Fred

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

[Wayne Rasband-2]

> On Aug 30, 2020, at 2:53 PM, Fred Damen <[hidden email]> wrote:
>
> Greetings,
>
> A while back I asked why sometimes hitting the up or down arrows in an
> ImageWindow would cause the contained Roi to move up and down, and
> sometimes the ImageWindow would zoom up(+) or down(-).  It turns out that
> the ImageJ.keyPressed method is a low level I/O method, and as such, gets
> called on every key pressed, including modifiers.

The ImageJ.keyPressed() method, which handles key presses in image windows, was calling IJ.shiftKeyDown() and IJ.controlKeyDown() by mistake. This is fixed in the ImageJ 1.53e11 daily build. When using the up and down arrow keys, ImageJ zooms in or out, instead of nudging the selection, when shift or control are pressed.

-wayne

> ImageJ.keyPressed/keyReleased stores the current state of the modifier
> keys.  Unfortunately, if a modifier key is pressed in a ImageJ window and
> then released while not in a ImageJ window, the current modifier status
> may not reflect the actual current status. In my case, if the control or
> shift key is pressed while in an ImageJ window and released outside and
> ImageJ window, then upon hitting the up or down arrows in a ImageWindow
> the zoom cmd would be run instead of the roi.nudge method being called.
>
> Previously, I had noticed that requesting a image to be duplicated, and
> then canceling, cleared this anomaly. It turns out that all you have to do
> is, within the ImageWindow press and release the shift, and then the
> control, keys to clear this anomaly.  It seems obvious now, but it stumped
> me for a long time; so hopefully knowing this will help others.
>
> I suspect, but have not tested, that calling KeyEvent.isShiftDown and
> KeyEvent.isControlDown methods instead of IJ.shiftKeyDown() and
> IJ.controlKeyDown may alleviate this issue.
>
> Thanks,
>
> Fred

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