java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)

Calling toolkit.getLockingKeyState(KeyEvent.VK_CAPS_LOCK) returns whether or not
caps lock is currently held down, not whether or not caps lock is currently
enabled. This makes it pretty much useless, and I can't seem to find another way
to check for caps lock buing enabled.

Try compiling the sample program; every second it prints the caps lock state.
Try pressing caps lock; not that getLockingKeyState only returns true if you are
holding caps lock while it is called, if you press caps lock once (to enable it)
and release, then you get false back.

import java.awt.Toolkit;
import java.awt.event.KeyEvent;

public class CapsProb {
  public static void main(String args[]) {
    for (;;) {
      try {
	Thread.sleep(1000);
      } catch(InterruptedException excep) {}
      System.out.println("Caps lock on? " +
			 Toolkit.getDefaultToolkit().getLockingKeyState(
			   KeyEvent.VK_CAPS_LOCK));
    }
  }
}
(Review ID: 116730) 
======================================================================




FULL PRODUCT VERSION :
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)

FULL OS VERSION :
 customer  Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
Under Windows, Toolkit.getLockingKeyState() works only if your application has created a Frame, and it may still return an incorrect result if the state changed when the focus was on a window other than the Frame.

I believe this is because the native Toolkit implementation uses the Win32 GetKeyboardState() API. If it used GetAsyncKeyState() instead, it would not be sensitive to whether the app has focus, and in fact wouldn't even require a Frame to be present in order to work correctly.

I consider this a bug, not an enhancement request. The documentation makes no mention of either of these prerequisites.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and run the program attached below.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The program should output "true" if the caps lock key is pressed.
ACTUAL -
The program emits an infinite series of "false"s.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------

import java.awt.*;
import java.awt.event.*;

public class test
{
	public static void main(String[] args) throws Exception
	{
		for (;;)
		{
			System.out.println(Toolkit.getDefaultToolkit().getLockingKeyState(KeyEvent.VK_CAPS_LOCK));
			Thread.sleep(1000);
		}
	}
}

---------- END SOURCE ----------
(Review ID: 191863)
======================================================================

N/A

Sounds like 4320043.  
  xxxxx@xxxxx   2001-02-11

Hmmm, actually I'm not sure they are related.  
  xxxxx@xxxxx   2001-02-11

Probably ought to be using GetKeyState instead of GetKeyboardState for win32.  
  xxxxx@xxxxx   2002-09-09

I believe the example provided is bogus because it does
not use any window! If cp is some visible AWT component,
cp.getToolkit().getLockingKeyState() works fine for me 
with JDK 1.3.1 under W2K.

I think this bug does not appear in Windows. In Linux, the
fix you give does not work.

I'm having a similar problem under Sun JDK 1.4.0 for Linux,
except for me it always returns true, instead of always
returning false. Go figure.  I'll have to retest under
windows and see if that makes it go away.

I had a similar problem with JDK 1.4.1 on Windows. I found 
out that the state got updated only after pressing some 
key. When I changed the CAPS lock state when the focus was 
outside my Java application and then set the focus back, I 
didn't get the state change. But, once I pressed some key I 
got the correct state.

I implemented bregman's solution with a Robot and now it works

This bug still exists in JDK 1.6.  It seems like using the native GetKeyState() is a simple solution.  Is Sun still planning to fix this?

I tried a Robot solution but it seemed unreliable.  The generated key press/release events weren't always delivered, perhaps due to thread timing issues.

I'm definitely having issues with this one. It seems to me more like it returns the state of the key when the application starts, and then continually returns the same value.