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

Bug #985395 reported by Jayanti Srivastava on 2012-04-19
32
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Sikuli
Medium
RaiMan

Bug Description

**** strange behavior on Mac Lion too:
The states are reported correctly, but have no influence at all neither for Robot actions nor the outside world.

--------------------------------------------

might be related to bug 894312

--------------------------------------------

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 ?

RaiMan (raimund-hocke) on 2012-04-19
summary: - unexpected behavior of env.isLockOn()
+ unexpected behavior of env.isLockOn() --- Java problem
RaiMan (raimund-hocke) wrote :

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
RaiMan (raimund-hocke) on 2012-04-19
description: updated
RaiMan (raimund-hocke) on 2012-11-02
Changed in sikuli:
status: Confirmed → In Progress
assignee: nobody → RaiMan (raimund-hocke)
RaiMan (raimund-hocke) on 2012-11-02
tags: added: fkt-type
RaiMan (raimund-hocke) on 2013-02-21
Changed in sikuli:
importance: Undecided → Low
RaiMan (raimund-hocke) on 2013-02-21
Changed in sikuli:
importance: Low → Medium
RaiMan (raimund-hocke) on 2013-09-11
Changed in sikuli:
milestone: none → 1.1.0
RaiMan (raimund-hocke) on 2013-09-11
description: updated
andrea (andrea-merli69) wrote :

Hi RaiMan do you have an idea when this bug will be solved in Sikuli rel 1.1.0?
thanks

RaiMan (raimund-hocke) wrote :

@andrea
see related question

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers