Comment 1 for bug 985395

Confirmed.

I checked with the Java features used by Sikuli directly and found, that
java.awt.Toolkit.getDefaultToolkit().getLockingKeyState(KeyEvent.VK_CAPS_LOCK)

does only report correctly at Java VM startup and when the script is run in the IDE by using the run shortcut ctrl-r.

Subsequent checks report the same state, though the real state has been changed either by using the java.awt.Robot.keyPress/keyRelease (used in the respective Sikuli features) or pressing the real key.

In the Java API there is a comment, that the change of the state may not be reported directly. But I did not find any information how to force it.

I tested with the following test script:
useRobot = False

from java.awt.event import KeyEvent as KE
key = KE.VK_CAPS_LOCK
ktext = "CAPS_LOCK is "

from java.awt import Toolkit as TK
tk = TK.getDefaultToolkit()

from java.awt import Robot as RB
rb = RB()

switchApp("Editor"); wait(1)
type("a", KeyModifier.CTRL)
type(Key.BACKSPACE)

popup("type some letters in notepad window and click OK")

state = tk.getLockingKeyState(key)
type(Key.ENTER)
type(ktext)
type(str(state))
type(Key.ENTER)

type(ktext+"getting switched ")
if useRobot:
    type("using Robot")
    rb.keyPress(key)
    rb.keyRelease(key)
else:
    type("using Toolkit")
    tk.setLockingKeyState(key, not state)
type(Key.ENTER)
type(ktext+"switched"+Key.ENTER)

type(ktext)
type(str(tk.getLockingKeyState(key)))
type(Key.ENTER)

popup("type some letters in notepad window")

Both switch methods (Robot and Toolkit) yield the same behavior.

this is the test out put from notepad window:

AAAAAA
CAPS_LOCK IS TRUE
CAPS_LOCK IS GETTING SWITCHED USING TOOLKIT
CAPS_LOCK is switched
CAPS_LOCK is True
AAAAA
manually switched
aaaaaa
CAPS_LOCK is True
CAPS_LOCK is getting switched using Toolkit
CAPS_LOCK IS SWITCHED
CAPS_LOCK IS TRUE
script run by mouse click run button
aaaaa
CAPS_LOCK is False
CAPS_LOCK is getting switched using Toolkit
CAPS_LOCK IS SWITCHED
CAPS_LOCK IS FALSE
script run with ctrl-a

all lines not beginning with CAPS_LOCK are entered manually.

*** the findings:
- the state is only reported correctly at start up
- subsequent checks do not show the correct state
- state changes are only reflected internally by the Robot actions, no effect on outside world
- manually changing state is correctly shown only when run with ctrl-r

**** conclusion: not useable that way