How to know when a user has really released a key in Java?
(Edited for clarity)
I want to detect when a user presses and releases a key in Java Swing, ignoring the keyboard auto repeat feature. I also would like a pure Java approach the works on Linux, Mac OS and Windows.
Requirements:
- When the user presses some key I want to know what key is that;
- When the user releases some key, I want to know what key is that;
- I want to ignore the system auto repeat options: I want to receive just one keypress event for each key press and just one key release event for each key release;
- If possible, I would use items 1 to 3 to know if the user is holding more than one key at a time (i.e, she hits 'a' and without releasing it, she hits "Enter").
The problem I'm facing in Java is that under Linux, when the user holds some key, there are many keyPress and keyRelease events being fired (because of the keyboard repeat feature).
I've tried some approaches with no success:
- Get the last time a key event occurred - in Linux, they seem to be zero for key repeat, however, in Mac OS they are not;
- Consider an event only if the current keyCode is different from the last one - this way the user can't hit twice the same key in a row;
Here is the basic (non working) part of code:
import java.awt.event.KeyListener;
public class Example implements KeyListener {
public void keyTyped(KeyEvent e) {
}
public void keyPressed(KeyEvent e) {
System.out.println("KeyPressed: "+e.getKeyCode()+", ts="+e.getWhen());
}
public void keyReleased(KeyEvent e) {
System.out.println("KeyReleased: "+e.getKeyCode()+", ts="+e.getWhen());
}
}
When a user holds a key (i.e, 'p') the system shows:
KeyPressed: 80, ts=1253637271673
KeyReleased: 80, ts=1253637271923
KeyPressed: 80, ts=1253637271923
KeyReleased: 80, ts=1253637271956
KeyPressed: 80, ts=1253637271956
KeyReleased: 80, ts=1253637271990
KeyPressed: 80, ts=1253637271990
KeyReleased: 80, ts=1253637272023
KeyPressed: 80, ts=1253637272023
...
At least under Linux, the JVM keeps resending all the key events when a key is being hold. To make things more difficult, on my system (Kubuntu 9.04 Core 2 Duo) the timestamps keep changing. The JVM sends a key new release and new key press with the same timestamp. This makes it hard to know when a key is really released.
Any ideas?
Thanks
This could be problematic. I can't remember for sure (it's been a long time), but it's likely the repeating-key feature (which is handled by the underlying operating system, not Java) isn't providing enough information for the JVM developer to distinguish those additional key events from the 'real' one. (I worked on this in the OS/2 AWT back in 1.1.x by the way).
From the javadoc for KeyEvent:
"Key pressed" and "key released" events are lower-level and depend on the platform and keyboard layout. They are generated whenever a key is pressed or released, and are the only way to find out about keys that don't generate character input (e.g., action keys, modifier keys, etc.). The key being pressed or released is indicated by the getKeyCode method, which returns a virtual key code.
As I recall from doing this in OS/2 (which at the time still had only the 2-event up/down flavor of keyboard handling like older versions of Windows, not the 3-event up/down/char flavor you get in more modern versions), I didn't report KeyReleased events any differently if the key was just being held down and the events auto-generated; but I suspect OS/2 didn't even report that information to me (can't remember for sure). We used the Windows reference JVM from Sun as our guide for developing our AWT - so I suspect if it were possible to report this information there, I'd have at least seen it on their end.
This question is duplicated here.
In that question, a link to the Sun bug parade is given, where some workaround is suggested.
I've made a hack implemented as an AWTEventListener that can be installed at the start of the application.
Basically, observe that the time between the RELEASED and the subsequent PRESSED is small - actually, it is 0 millis. Thus, you can use that as a measure: Hold the RELEASED for some time, and if a new PRESSED comes right after, then swallow the RELEASED and just handle the PRESSED (And thus you will get the same logic as on Windows, which obviously is the correct way). However, watch for the wrap-over from one millisecond to the next (I've seen this happen) - so use at least 1 ms to check. To account for lags and whatnots, some 20-30 milliseconds probably won't hurt.
I've refined stolsvik hack to prevent repeating of KEY_PRESSED and KEY_TYPED events as well, with this refinement it works correctly under Win7 (should work everywhere as it truly watches out for KEY_PRESSED/KEY_TYPED/KEY_RELEASED events).
Cheers! Jakub
package com.example;
import java.awt.AWTEvent;
import java.awt.Component;
import java.awt.EventQueue;
import java.awt.Toolkit;
import java.awt.event.AWTEventListener;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.awt.event.KeyEvent;
import java.util.HashMap;
import java.util.HashSet;
import java.util.Map;
import java.util.Set;
import javax.swing.Timer;
/**
* This {@link AWTEventListener} tries to work around for KEY_PRESSED / KEY_TYPED/ KEY_RELEASED repeaters.
*
* If you wish to obtain only one pressed / typed / released, no repeatings (i.e., when the button is hold for a long time).
* Use new RepeatingKeyEventsFixer().install() as a first line in main() method.
*
* Based on xxx
* Which was done by Endre Stølsvik and inspired by xxx (hyperlinks stipped out due to stackoverflow policies)
*
* Refined by Jakub Gemrot not only to fix KEY_RELEASED events but also KEY_PRESSED and KEY_TYPED repeatings. Tested under Win7.
*
* If you wish to test the class, just uncomment all System.out.println(...)s.
*
* @author Endre Stølsvik
* @author Jakub Gemrot
*/
public class RepeatingKeyEventsFixer implements AWTEventListener {
public static final int RELEASED_LAG_MILLIS = 5;
private static boolean assertEDT() {
if (!EventQueue.isDispatchThread()) {
throw new AssertionError("Not EDT, but [" + Thread.currentThread() + "].");
}
return true;
}
private Map<Integer, ReleasedAction> _releasedMap = new HashMap<Integer, ReleasedAction>();
private Set<Integer> _pressed = new HashSet<Integer>();
private Set<Character> _typed = new HashSet<Character>();
public void install() {
Toolkit.getDefaultToolkit().addAWTEventListener(this, AWTEvent.KEY_EVENT_MASK);
}
public void remove() {
Toolkit.getDefaultToolkit().removeAWTEventListener(this);
}
@Override
public void eventDispatched(AWTEvent event) {
assert event instanceof KeyEvent : "Shall only listen to KeyEvents, so no other events shall come here";
assert assertEDT(); // REMEMBER THAT THIS IS SINGLE THREADED, so no need
// for synch.
// ?: Is this one of our synthetic RELEASED events?
if (event instanceof Reposted) {
//System.out.println("REPOSTED: " + ((KeyEvent)event).getKeyChar());
// -> Yes, so we shalln't process it again.
return;
}
final KeyEvent keyEvent = (KeyEvent) event;
// ?: Is this already consumed?
// (Note how events are passed on to all AWTEventListeners even though a
// previous one consumed it)
if (keyEvent.isConsumed()) {
return;
}
// ?: KEY_TYPED event? (We're only interested in KEY_PRESSED and
// KEY_RELEASED).
if (event.getID() == KeyEvent.KEY_TYPED) {
if (_typed.contains(keyEvent.getKeyChar())) {
// we're being retyped -> prevent!
//System.out.println("TYPED: " + keyEvent.getKeyChar() + " (CONSUMED)");
keyEvent.consume();
} else {
// -> Yes, TYPED, for a first time
//System.out.println("TYPED: " + keyEvent.getKeyChar());
_typed.add(keyEvent.getKeyChar());
}
return;
}
// ?: Is this RELEASED? (the problem we're trying to fix!)
if (keyEvent.getID() == KeyEvent.KEY_RELEASED) {
// -> Yes, so stick in wait
/*
* Really just wait until "immediately", as the point is that the
* subsequent PRESSED shall already have been posted on the event
* queue, and shall thus be the direct next event no matter which
* events are posted afterwards. The code with the ReleasedAction
* handles if the Timer thread actually fires the action due to
* lags, by cancelling the action itself upon the PRESSED.
*/
final Timer timer = new Timer(RELEASED_LAG_MILLIS, null);
ReleasedAction action = new ReleasedAction(keyEvent, timer);
timer.addActionListener(action);
timer.start();
ReleasedAction oldAction = (ReleasedAction)_releasedMap.put(Integer.valueOf(keyEvent.getKeyCode()), action);
if (oldAction != null) oldAction.cancel();
// Consume the original
keyEvent.consume();
//System.out.println("RELEASED: " + keyEvent.getKeyChar() + " (CONSUMED)");
return;
}
if (keyEvent.getID() == KeyEvent.KEY_PRESSED) {
if (_pressed.contains(keyEvent.getKeyCode())) {
// we're still being pressed
//System.out.println("PRESSED: " + keyEvent.getKeyChar() + " (CONSUMED)");
keyEvent.consume();
} else {
// Remember that this is single threaded (EDT), so we can't have
// races.
ReleasedAction action = (ReleasedAction) _releasedMap.get(keyEvent.getKeyCode());
// ?: Do we have a corresponding RELEASED waiting?
if (action != null) {
// -> Yes, so dump it
action.cancel();
}
_pressed.add(keyEvent.getKeyCode());
//System.out.println("PRESSED: " + keyEvent.getKeyChar());
}
return;
}
throw new AssertionError("All IDs should be covered.");
}
/**
* The ActionListener that posts the RELEASED {@link RepostedKeyEvent} if
* the {@link Timer} times out (and hence the repeat-action was over).
*/
protected class ReleasedAction implements ActionListener {
private final KeyEvent _originalKeyEvent;
private Timer _timer;
ReleasedAction(KeyEvent originalReleased, Timer timer) {
_timer = timer;
_originalKeyEvent = originalReleased;
}
void cancel() {
assert assertEDT();
_timer.stop();
_timer = null;
_releasedMap.remove(Integer.valueOf(_originalKeyEvent.getKeyCode()));
}
@Override
public void actionPerformed(@SuppressWarnings("unused") ActionEvent e) {
assert assertEDT();
// ?: Are we already cancelled?
// (Judging by Timer and TimerQueue code, we can theoretically be
// raced to be posted onto EDT by TimerQueue,
// due to some lag, unfair scheduling)
if (_timer == null) {
// -> Yes, so don't post the new RELEASED event.
return;
}
//System.out.println("REPOST RELEASE: " + _originalKeyEvent.getKeyChar());
// Stop Timer and clean.
cancel();
// Creating new KeyEvent (we've consumed the original).
KeyEvent newEvent = new RepostedKeyEvent(
(Component) _originalKeyEvent.getSource(),
_originalKeyEvent.getID(), _originalKeyEvent.getWhen(),
_originalKeyEvent.getModifiers(), _originalKeyEvent
.getKeyCode(), _originalKeyEvent.getKeyChar(),
_originalKeyEvent.getKeyLocation());
// Posting to EventQueue.
_pressed.remove(_originalKeyEvent.getKeyCode());
_typed.remove(_originalKeyEvent.getKeyChar());
Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(newEvent);
}
}
/**
* Marker interface that denotes that the {@link KeyEvent} in question is
* reposted from some {@link AWTEventListener}, including this. It denotes
* that the event shall not be "hack processed" by this class again. (The
* problem is that it is not possible to state
* "inject this event from this point in the pipeline" - one have to inject
* it to the event queue directly, thus it will come through this
* {@link AWTEventListener} too.
*/
public interface Reposted {
// marker
}
/**
* Dead simple extension of {@link KeyEvent} that implements
* {@link Reposted}.
*/
public static class RepostedKeyEvent extends KeyEvent implements Reposted {
public RepostedKeyEvent(@SuppressWarnings("hiding") Component source,
@SuppressWarnings("hiding") int id, long when, int modifiers,
int keyCode, char keyChar, int keyLocation) {
super(source, id, when, modifiers, keyCode, keyChar, keyLocation);
}
}
}
I have found a solution to this problem without relying on timing (which according to some users is not necessarily consistent 100% of the time) but instead by issuing extra key presses to override the key repeat.
To see what I mean, try holding a key and then hitting another mid-stream. The repeat will stop. It seems that, on my system at least, the key hits issued by Robot also have this effect.
For an example implementation, tested in Windows 7 & Ubuntu, see:
http://elionline.co.uk/blog/2012/07/12/ignore-key-repeats-in-java-swing-independently-of-platform/
Also, thanks to Endre Stolsvik's solution for showing me how to do a global event listener! Appreciated.
Save the timestamp of the event (arg0.when()) in keyReleased. If the next keyPressed event is for the same key and has the same timestamp, it is an autorepeat.
If you hold down multiple keys, X11 only autorepeats the last key pressed. So, if you hold down 'a' and 'd' you'll see something like:
a down
a up
a down
d down
d up
d down
d up
a up