You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Think about making a game. Wanting to update the screen but then waiting for user input. I guess you could run everything else in a thread but the keystroke input waiting. But then again why can't we run the keystroke detection in a thread?
a little late but for others looking for this. This code is only testes for the new Version beeing developed under #79
fromthreadingimportThreadfromtimeimporttime, sleepfromreadcharimportkey, readkey# construct an inverted code -> key-name mapping# we need to revese the items so that aliases won't overrive the original name later onknown_keys= {v: kfork, vinreversed(vars(key).items()) ifnotk.startswith("__")}
defkeylogger():
globalrunningprint("starting keylogger...")
whilerunning:
try:
data=readkey()
exceptKeyboardInterrupt:
running=Falsebreakifdatainknown_keys:
data=known_keys[data]
print(f"{data}-key was pressed")
print("stopping keylogger...")
defmain():
whilerunning:
print(f"LOG: current time is {time()}")
sleep(1)
running=Trueif__name__=="__main__":
Thread(name="keylogger", target=keylogger).start()
main()
For cases where a timeout is required, spawning a subprocess instead of a thread means it can be killed. See the following:
frommultiprocessingimportProcessfromtimeimportsleep, timefromreadcharimportkey, readkey# construct an inverted code -> key-name mapping# we need to revese the items so that aliases won't overrive the original name later onknown_keys= {v: kfork, vinreversed(vars(key).items()) ifnotk.startswith("__")}
defkeylogger():
print("starting keylogger...")
whileTrue:
try:
data=readkey()
exceptKeyboardInterrupt:
breakifdatainknown_keys:
data=known_keys[data]
print(f"{data}-key was pressed")
if__name__=="__main__":
p=Process(name="keylogger", target=keylogger)
p.start()
sleep(5)
print("timeout..")
p.kill()
I have a strange case where CTRL+C causes readchar.readkey() to block forever.
The thread calling readchar.readkey() is a background thread (reason explained below)
Unfortunately I can't reproduce it in a simple code snippet, It occures in an app with a lot of things going on.
I was able to solve the problem by replacing readchar.config.INTERRUPT_KEYS with an empty array:
readchar.config.INTERRUPT_KEYS= []
@AuHau not blocking the main thread is essential in use cases where you want to intercept os signals, the main thread must be paused with signal.pause()
@max-l without a way to reproduce, I can really help you. However, here are some thought on the matter:
When you start the separate thread, you also need to terminate both threads in some way. You may have had cases where you had to press CTRL+C two times to stop the program, once for each thread. One other way is to set a flag when one terminates, that also stops the other one (like running in the example)
Now if you mess around with SIGINT you might get cases, where a CTRL+C doesn't reach readchar properly, because it is interrupted beforehand or something similar.
If you find a way to reproduce this Problem, feel free to open an issue
changed the title [-]is there any example of running this in a background thread?[/-][+]Example: running this in a background thread?[/+]on Nov 9, 2022
Activity
AuHau commentedon Mar 12, 2019
Hmm not sure, but to be honest, why would you like to do that? It does not really make sense to me...
GrandMoff100 commentedon Nov 16, 2020
Think about making a game. Wanting to update the screen but then waiting for user input. I guess you could run everything else in a thread but the keystroke input waiting. But then again why can't we run the keystroke detection in a thread?
Cube707 commentedon Jul 9, 2022
a little late but for others looking for this. This code is only testes for the new Version beeing developed under #79
For cases where a timeout is required, spawning a subprocess instead of a thread means it can be killed. See the following:
max-l commentedon Oct 31, 2022
I have a strange case where CTRL+C causes readchar.readkey() to block forever.
The thread calling readchar.readkey() is a background thread (reason explained below)
Unfortunately I can't reproduce it in a simple code snippet, It occures in an app with a lot of things going on.
I was able to solve the problem by replacing readchar.config.INTERRUPT_KEYS with an empty array:
@AuHau not blocking the main thread is essential in use cases where you want to intercept os signals, the main thread must be paused with signal.pause()
Cube707 commentedon Nov 6, 2022
@max-l without a way to reproduce, I can really help you. However, here are some thought on the matter:
When you start the separate thread, you also need to terminate both threads in some way. You may have had cases where you had to press
CTRL+Ctwo times to stop the program, once for each thread. One other way is to set a flag when one terminates, that also stops the other one (likerunningin the example)Now if you mess around with
SIGINTyou might get cases, where aCTRL+Cdoesn't reach readchar properly, because it is interrupted beforehand or something similar.If you find a way to reproduce this Problem, feel free to open an issue
[-]is there any example of running this in a background thread?[/-][+]Example: running this in a background thread?[/+]Cube707 commentedon Nov 9, 2022
As this is only for documentation purposous, I will lock it.
If you have problem or suggestions, feel free to open another issue