unexpected behavior of env.isLockOn() --- Java problem
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| SikuliX |
In Progress
|
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.
keyDown(
keyUp(Key.
print str(Env.
kindly let me know if we are using isLockOn() incorrectly, or is this a bug ?
| summary: |
- unexpected behavior of env.isLockOn() + unexpected behavior of env.isLockOn() --- Java problem |
| RaiMan (raimund-hocke) wrote | #1 |
| Changed in sikuli: | |
| status: | New → Confirmed |
| description: | updated |
| Changed in sikuli: | |
| status: | Confirmed → In Progress |
| assignee: | nobody → RaiMan (raimund-hocke) |
| tags: | added: fkt-type |
| Changed in sikuli: | |
| importance: | Undecided → Low |
| Changed in sikuli: | |
| importance: | Low → Medium |
| Changed in sikuli: | |
| milestone: | none → 1.1.0 |
| description: | updated |
| andrea (andrea-merli69) wrote | #2 |
| RaiMan (raimund-hocke) wrote | #3 |
Confirmed.
I checked with the Java features used by Sikuli directly and found, that
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.
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.getDefaultTo
from java.awt import Robot as RB
rb = RB()
switchApp(
type("a", KeyModifier.CTRL)
type(Key.BACKSPACE)
popup("type some letters in notepad window and click OK")
state = tk.getLockingKe
type(Key.ENTER)
type(ktext)
type(str(state))
type(Key.ENTER)
type(ktext+"getting switched ")
if useRobot:
type("using Robot")
rb.
rb.
else:
type("using Toolkit")
tk.
type(Key.ENTER)
type(ktext+
type(ktext)
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