Open fufesou opened 1 year ago
Ohh I don't remember. Windows API is just weird sometimes, and some which seems innocuous does modify next results.
It might be removable, I don't have the specifics in mind.
Thanks. I've commented out the line in my fork. If something is wrong, I'll reply here.
Please just let this issue open. Maybe someone can reply here.
Windows API is just weird sometimes, and some which seems innocuous does modify next results.
Yes, it's wired.
However, if GetKeyState(aVKCode) is called immediately prior to GetKeyboardState(aByteArray), for any value of aVKCode, even if the return value is discarded, then GetKeyboardState(aByteArray) will provide the correct non-zero state of the held SHIFT key when the application is not in focus.
But if GetKeyState(aVKCode) is called immediately prior to GetKeyboardState(aByteArray), some accents cannot be typed correctly. As if Shift
is not pressed.
When grabbing keyboard, local input in some other windows:
error Keybaord Layout
ö turns out ô French
ö turns out o Portuguese(Brazil)
ô turns out õ Portuguese(Brazil)
ò turns out ó Portuguese(Brazil)
Welcome to windows !
And thanks for digging that up. I have no idea if a solution is at all imaginable then.
Get a problem in windows where the input from the scanner changes, e.g. program always read correct barcode tLds6pDr
, but input into notepad (or another progam) is unstable tLdS6pDr
, tlds6pDr
or tLds^PDr
, as if with the shift key pressed.
Is it possible at least allow disable this check in builder? This makes it impossible to use (
https://github.com/Narsil/rdev/blob/f4d847620bd94f6758042f8daf63e16491d92fb9/src/windows/keyboard.rs#L50
Hi, I'm confused why get shift state is needed here. If I comment out this line, the bug is fixed https://github.com/rustdesk/rustdesk/issues/2670. And there seems no other side effects.
Just run grab in examples to reproduce this issue.