sikuli-driver team mailing list archive
-
sikuli-driver team
-
Mailing list archive
-
Message #54616
[Bug 1861588] Re: Keyboard commands don't send when AutoDetectKeyboardLayout=True
** Changed in: sikuli
Status: New => Invalid
--
You received this bug notification because you are a member of Sikuli
Drivers, which is subscribed to Sikuli.
https://bugs.launchpad.net/bugs/1861588
Title:
Keyboard commands don't send when AutoDetectKeyboardLayout=True
Status in Sikuli:
Invalid
Bug description:
Sikuli 2.0.2
I had been previously using SikuliX 1.1.3 and noticed upon updating to
1.1.4 / 2.0.2 that my keyDown/keyUp and type commands were no longer
registering in the target application. There were no errors logged in
debug and Sikuli did report that it was pressing the desired key but
there was no response from the application.
I went digging through the source files and landed on the method
'doKeyPress' in RobotDesktop.java. Looking at how behavior changed
between 1.1.3 and 2.0.2 I noticed that when
AutoDetectKeyboardLayout=True it will attempt to send the key using
'User32.INSTANCE.SendInput' and otherwise it falls back to the same
behavior that 1.1.3 had.
Once I set 'Settings.AutoDetectKeyboardLayout=False' at the start of
my script Sikuli started behaving as expected and was able to send key
commands into the target application again.
Not sure if this is so much a bug but I've seen numerous reports of
people having issues with RDP and Citrix sessions where they needed to
run as administrator and other workarounds. Of note the application I
am targeting is NOT a remote desktop window or similar application,
but it seems to ignore inputs the same as those applications. Perhaps
something in the documentation to let people know that some
applications might require AutoDetectKeyboardLayout=False, or an
option that enforces the old behavior used in versions prior to 1.1.4
that doesn't require disabling auto detection of keyboard layout?
To manage notifications about this bug go to:
https://bugs.launchpad.net/sikuli/+bug/1861588/+subscriptions
References