GetAsyncKeyState and some problems? - user32

Why do i get more than 1 (a few hundred) key hit on a single press while using GetAsyncKeyState. It prints a hundred of a same key while i just pressed it once.
Thanks,

GetAsyncKeyState tells you the state of the keyboard, whether a key is down/up, not whether it has been pressed since last call. If you call it in a loop, you will get "key is down" for as long as you keep the key down - and that loop executes a lot faster than you can move your fingers.
If you want keyboard events handle WM_KEYDOWN and WM_KEYUP.
If you want a global hotkey, use RegisterHotKey

Related

Calling a function, and then sending a key in neovim

map z. <Cmd>call repeat(VSCodeNotify('editor.action.commentLine')j, v:count1)<CR>
The idea is to call the vscode command for commenting, and then the down key. With that, if I pass 5z., the next 5 lines get commented out
This code doesn't work. Does work if I remove j (but with that, I don't get the wanted behavior)
The repeat command also doesn't work. you'd expect the comment function to cancel out if you call it twice (it's a "toggle comment" function), but it only executes once, no matter what number I input

How screen handling program(eg.vi, less) work?

Suppose I'm reading a document in vi. When I reach the end of the screen and press the arrow down key, a new screen including the contents of the next line is printed in the terminal.
I wonder how this process is implemented.
Is vi process raise SIGTSTP and call signal handler to continue the process with new screen including next line?
Is ... process raise SIGTSTP and call signal handler ...
No.
The program first performs a tcsetattr() (which internally performs a special ioctl()) so the keyboard input is not handled line-wise but key-wise.
Then it prints out 25 lines.
Now it simply uses read() to wait for a key pressed.
If you press the DOWN key, one additional line is printed.
If you press the UP key (in the case of less), it is a bit more tricky; depending on the terminal used, some "escape sequence" (a special combination of bytes) is written to the screen using write(). This will cause the screen to be scrolled down. Then another "escape sequence" is written which places the cursor to the top left of the screen and one line of text is printed at the top of the screen.
When this is done, the program waits for the next key using read() ...
Signals are not involved.

How to make vim print the key i pressed directly when i have mapped this key with another one?

When I map 2 keys together for example <Tab><Space> and press the first one Vim will first wait to see if i press Space before printing the tabulation.
I would like to know if it is possible to make vim print the tabulation first and then waiting for an eventual Space key for mapping.
Thank You !

Pyautogui - When using code that use special keys, the key seem stuck at times

I am getting a weird behavior while using pyautogui hotkey; where the special key used at times does "stick" and cause the subsequent text printed with pyautogui.typewrite() function to be printed incorrectly.
For example, this statement ran on OSX will cause shift to stick at random; causing the output to be printed capitalized.
pyautogui.hotkey("command", "shift", "f")
time.sleep(3)
pyautogui.typewrite("reference_file2.txt")
This will open the "recents" window in Finder, wait 3 seconds then will type a filename which should (or should not be) in the recents window. Sometimes the output of typewrite is printed like if Shift key was pressed.
So instead of
reference_file2.txt
You will see
REFERENCE_FILE#>TXT
which is exactly what you get if you type the original string with Shift key pressed.
Is this a bug in the hotkey function of pyautogui? Or am I supposed to do something to ensure that the keys pressed with hotkey is released, before moving on with the next statement? The documentation of pyautogui specify that the hotkey function does equal to a keypress and keyrelease sequence, so no action should be required, right?

Is there a typeahead buffer for key presses in Linux terminal?

Does Linux buffer keys typed in terminal so that you can read them later one key at a time?
I am asking because I want to catch ESC and arrow key presses and can't find a way to reliably read the codes. I put terminal in non-canonical mode and want program to block if there is no input, but if there is, I want to fetch only one key press for processing.
Update 2: Arrow keys is just an example. I need to identify key presses even for the keys with unknown escape sequences for my program.
There are two conflicting cases:
read(1) returns one character. For both function keys and ESC key this character will be 0x1b. To check if it was an arrow key, you need to read(1), which will block if only single ESC is pressed.
Solution: blocked read(1), non-blocked read(1)
Problem: if second read didn't match any function key, it may mean that it was buffered ESC followed by some sequence, or an unknown function key. How to detect unknown function key press?
read(4) returns at most 4 characters, but if you press ESC four times to let it buffer, you'll get a string of four 0x1b. The same problem to find out if there is an unknown function key press as above.
Can anybody explain how to deal with these problems in Linux terminal, or at least post a proof that Linux just doesn't have input buffer for keys?
You should read up on VT100 escape sequences.
You've discovered that the character code for the escape button (which is sent as a real character, but tends to be used almost exclusively for signalling the beginning of an escape sequence) is 0x1b.
To move the cursor UP: <ESC>[{COUNT}A
To move the cursor DOWN: <ESC>[{COUNT}B
To move the cursor RIGHT: <ESC>[{COUNT}C
To move the cursor LEFT: <ESC>[{COUNT}D
You can test these yourself by typing them into the terminal. Just type the keys one after another. My terminal does not recognize the count argument, but will work successfully if I type <ESC>[X (for X in A,B,C,D).
If your terminal isn't in VT100 mode, look up the escape sequences for whichever mode it's in. You might realize that depending too much on terminal specific escape codes restricts your program to one specific terminal type.

Resources