Bug - Fixed unintended jump-to searching behavior

[Veracity]

I am on a Mac. When I open the Item Manager and use "command-a" to "select all", it now jumps to the first "a" item. That's a change. Unintended, I hope, since I used the old behavior - which is consistent with command-a in every other application - all the time.

 

[Catch-22]

I am on a Mac. When I open the Item Manager and use "command-a" to "select all", it now jumps to the first "a" item. That's a change. Unintended, I hope, since I used the old behavior - which is consistent with command-a in every other application - all the time.

Did 11612 fix this?

 

[Veracity]

(By the way, I just reported a bug over on the 11610 revision, since that was probably where it was introduced. Needless to say, I always run with the latest code, so I was running with this version when I encountered the problem. Since it is extremely doubtful that this commit caused the issue, I reported the bug over at the likely place of introduction...)

 

[Catch-22]

I would think that command-a shouldn't fire a keyTyped event on a Mac. Is there a particular reason why it would?

keyTyped should only fire if an actually representable unicode character would be typed as a result of the key combination. For example, ctrl+a doesn't cause this behaviour in Windows.

 

[roippi]

I moved some posts over from the svn feed to here, since the discussion was in two separate threads and I wanted it in one place.

Basically, this is not intended behavior, but it seems like buggy (or at least inconsistent and poorly documented) behavior in Java.

I would think that command-a shouldn't fire a keyTyped event on a Mac. Is there a particular reason why it would?

I don't know why it would either. KeyTyped is supposed to be a high-level event that implies the user typed a letter; the whole point of it existing is so that we don't have to worry about platform-specific keypress events like this. And, like you say, control-a does NOT fire a KeyTyped event on windows, so I have to assume this is a Java bug. One that we can provide a workaround for, but still. Quick googling shows that other software has had to work around this issue as well. Though I don't see that anyone has reported it to Oracle, so maybe that's a thing I should do.

(By the way, I just reported a bug over on the 11610 revision, since that was probably where it was introduced. Needless to say, I always run with the latest code, so I was running with this version when I encountered the problem. Since it is extremely doubtful that this commit caused the issue, I reported the bug over at the likely place of introduction...)

You are correct, the upside of r11612 is that you can click on a column other than the name column, do meta-a, and you won't get the undesirable behavior. Still, not ideal.

 

[roippi]

Try r11613?

 

[Veracity]

Much better. Thanks.