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()
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
Confirmed.
I checked with the Java features used by Sikuli directly and found, that Toolkit. getDefaultToolk it().getLocking KeyState( KeyEvent. VK_CAPS_ LOCK)
java.awt.
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 olkit()
tk = TK.getDefaultTo
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.getLockingKe yState( key)
type(Key.ENTER)
type(ktext)
type(str(state))
type(Key.ENTER)
type(ktext+"getting switched ") keyPress( key) keyRelease( key) setLockingKeySt ate(key, not state) "switched" +Key.ENTER)
if useRobot:
type("using Robot")
rb.
rb.
else:
type("using Toolkit")
tk.
type(Key.ENTER)
type(ktext+
type(ktext) tk.getLockingKe yState( key)))
type(str(
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