sikuli-driver team mailing list archive

[RaiMan <rmhdevelop@xxxxxx>]

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

** Changed in: sikuli
       Status: New => Confirmed

-- 
You received this bug notification because you are a member of Sikuli
Drivers, which is subscribed to Sikuli.
https://bugs.launchpad.net/bugs/985395

Title:
  unexpected behavior of env.isLockOn() --- Java problem

Status in Sikuli:
  Confirmed

Bug description:
  Hi,
  I am using sikuli X-1.0rc3, windows xp 32 bit

  and trying to get the current state of CAPS LOCK key - using isLockOn().
  But surprisingly it does not seem to work - at least as I expected.

  It works correctly for the first time - but the second call returns
  whatever was returned by it for the first time.

  For example, if caps lock is on, then first isLockOn() returns True,
  but thereafter if the capslock state changes to off, then still
  isLockOn() returns True.

  for this I used the following code, in sikuli ide

  print str(Env.isLockOn(Key.CAPS_LOCK))
  keyDown(Key.CAPS_LOCK)
  keyUp(Key.CAPS_LOCK)
  print str(Env.isLockOn(Key.CAPS_LOCK))

  kindly let me know if we are using isLockOn() incorrectly, or is this
  a bug ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/sikuli/+bug/985395/+subscriptions