Remembers ctrl and shift after release about pynput HOT 11 CLOSED

Thank you for the report. I will look into it in the coming days, as I
think it definitely is a pynput issue; control keys on Windows are among
the more challenging parts of the library.

Could you tell me what keyboard layout you use?

On 21 Sep 2016 22:17, "arcane99" [email protected] wrote:

Good day, thanks for creating this great library.

Python 2.7, release 1.1 of pynput, Windows 10

I am experiencing an odd issue with the keyboard monitor and control/shift
keys.

On release of the control or shift key, the application remembers the key
and the next input logged is then a special character.
For example

• if I press 'a' and release, keyboard monitor logs a u'a'
• if I press 'left control' and release, keyboard monitor logs a
  'Key.ctrl_l'
• if I then press 'a' and release, keyboard monitor logs a u'\x01'
• if I then press 'a' and release again, keyboard monitor logs a u'a'

A similar thing is observed with the shift key. A capital 'A' is
recognized on press of 'a' (without the shift). This means that the key
press logged after a control or shift press and release is incorrect.

Not sure if this is in fact a pynput issue.

Regards

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjOYzJbw9XtBreG2m-0RYvGSHVhN3M4ks5qsZDjgaJpZM4KDO4b
.

from pynput.

Hi. It's a standard US keyboard layout, no custom keys. I can test with a
different layout tomorrow. I'll also see if I can replicate on a Linux
machine.

Just so you are aware there is a typo in mouse monitor on_scroll example in
documentation, the function is missing the x and y parameters.

def on_scroll(dx, dy): should be

def on_scroll(x,y,dx, dy):

Regards

On 21 Sep 2016 10:23 PM, "moses-palmer" [email protected] wrote:

Thank you for the report. I will look into it in the coming days, as I
think it definitely is a pynput issue; control keys on Windows are among
the more challenging parts of the library.

Could you tell me what keyboard layout you use?

On 21 Sep 2016 22:17, "arcane99" [email protected] wrote:

Good day, thanks for creating this great library.

Python 2.7, release 1.1 of pynput, Windows 10

I am experiencing an odd issue with the keyboard monitor and
control/shift
keys.

On release of the control or shift key, the application remembers the key
and the next input logged is then a special character.
For example

• if I press 'a' and release, keyboard monitor logs a u'a'
• if I press 'left control' and release, keyboard monitor logs a
  'Key.ctrl_l'
• if I then press 'a' and release, keyboard monitor logs a u'\x01'
• if I then press 'a' and release again, keyboard monitor logs a u'a'

A similar thing is observed with the shift key. A capital 'A' is
recognized on press of 'a' (without the shift). This means that the key
press logged after a control or shift press and release is incorrect.

Not sure if this is in fact a pynput issue.

Regards

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAjOYzJbw9XtBreG2m-
0RYvGSHVhN3M4ks5qsZDjgaJpZM4KDO4b>
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#2 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVUbsx7_jIeOuLxLiKsGWEcOOdIfJY9Iks5qsZJRgaJpZM4KDO4b
.

from pynput.

After further investigation, I have located the error to ToUnicodeEx.

The issue is not limited to ctrl; pressing shift also keeps the state until the next key press. I will look into the keyboard state buffer returned by GetKeyboardState.

from pynput.

I have an attempt at a solution ready here.

It fixes the issue by postponing handling and sending the keyboard event until all system hooks have executed by posting a message to the listener main loop. According to the documentation of LowLevelKeyboardProc, the keyboard state is not updated during the system hook callback, and thus GetKeyboardState will return an incorrect shift state.

Please note that this bug fix required a rather large rewrite of the Windows backend. I have not yet merged the fixup branch into master as I will need to add some tests, and figure out a way to actually have the tests pass on Windows.

I would appreciate your feedback on the bug fix, especially if actually resolves the issues of your use case, and whether you notice any regressions.

from pynput.

Okay, will do. Give me a day or two.

What other changes should I expect as a result of the fix? Is it working as
expected in your testing now?

On 26 Sep 2016 12:18 AM, "moses-palmer" [email protected] wrote:

I have an attempt at a solution ready here
https://github.com/moses-palmer/pynput/tree/fixup-listeners.

It fixes the issue by postponing handling and sending the keyboard event
until all system hooks have executed by posting a message to the listener
main loop. According to the documentation of LowLevelKeyboardProc
https://msdn.microsoft.com/en-us/library/windows/desktop/ms644985(v=vs.85).aspx,
the keyboard state is not updated during the system hook callback, and thus
GetKeyboardState will return an incorrect shift state.

Please note that this bug fix required a rather large rewrite of the
Windows backend. I have not yet merged the fixup branch into master as I
will need to add some tests, and figure out a way to actually have the
tests pass on Windows.

I would appreciate your feedback on the bugfix, especially if actually
resolves the issues of your use case, and whether you notice any
regressions.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#2 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVUbs_d108XkZlfAEmIugRQsfAXcwtDlks5qtvNQgaJpZM4KDO4b
.

from pynput.

The fix changes the code only for the keyboard listener, so no other parts
of the library should be affected.

All simple keyboard listener tests pass, as does a sample app to mimic the
behaviour you described in this but report. Unfortunately, because of the
terrible terminal support on Windows, many of the keyboard tests do not,
and never have.

Before merging this branch, I will add a test for modifier keys, and I will
look into finding a way to make the tests pass on Windows as well.

On 26 Sep 2016 07:58, "arcane99" [email protected] wrote:

Okay, will do. Give me a day or two.

What other changes should I expect as a result of the fix? Is it working as
expected in your testing now?

On 26 Sep 2016 12:18 AM, "moses-palmer" [email protected] wrote:

I have an attempt at a solution ready here
https://github.com/moses-palmer/pynput/tree/fixup-listeners.

It fixes the issue by postponing handling and sending the keyboard event
until all system hooks have executed by posting a message to the listener
main loop. According to the documentation of LowLevelKeyboardProc
<https://msdn.microsoft.com/en-us/library/windows/desktop/
ms644985(v=vs.85).aspx>,
the keyboard state is not updated during the system hook callback, and thus
GetKeyboardState will return an incorrect shift state.

Please note that this bug fix required a rather large rewrite of the
Windows backend. I have not yet merged the fixup branch into master as I
will need to add some tests, and figure out a way to actually have the
tests pass on Windows.

I would appreciate your feedback on the bugfix, especially if actually
resolves the issues of your use case, and whether you notice any
regressions.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#2 (comment),
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AVUbs_
d108XkZlfAEmIugRQsfAXcwtDlks5qtvNQgaJpZM4KDO4b>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#2 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjOYxYlknhOwqnkxCT9vBXqDmz182gzks5qt17ygaJpZM4KDO4b
.

from pynput.

I did discover another bug in the Windows backend, and after resolving it all tests except the one depending on the terminal encoding (faking typing a non-ASCII string and reading it from stdin) pass, so I have merged the fixup branch and made a release.

Thank you again for your report. I will now close this issue.

from pynput.

Hi. Performing a pip install --upgrade; gives the following error now
Traceback (most recent call last):
File " automateitcapture.py", line 4, in
from pynput import mouse,keyboard
File " lib\site-packages\pynput__init__.py", line 18, in
from . import keyboard
File " lib\site-packages\pynput\keyboard__init__.py", line 36, in
from ._win32 import KeyCode, Key, Controller, Listener
File " lib\site-packages\pynput\keyboard_win32.py", line 21, in
from pynput._util.win32 import *
File " lib\site-packages\pynput_util\win32.py", line 374, in
class KeyTranslator(object):
File " lib\site-packages\pynput_util\win32.py", line 392, in KeyTranslator
wintypes.LPDWORD)
AttributeError: 'module' object has no attribute 'LPDWORD'

from pynput.

Sorry about that---it appears that LPDWORD was introduced in Python 3.2.

I have uploaded a new release with a fix---1.1.2.

from pynput.

Thanks for the extremely quick responses. Working great now.

Ps: Do you sleep? ;)

from pynput.

Great to hear!

Yes, I do sleep; it's the magic of time zones at work ;-)

On 26 Sep 2016 8:54 p.m., "arcane99" [email protected] wrote:

Thanks for the extremely quick responses. Working great now.

Ps: Do you sleep? ;)

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#2 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjOYzYB8Pm8AXDa_-nVFbP5HdkEbv-Zks5quBTggaJpZM4KDO4b
.

from pynput.