I'm trying to detect fake user input, in other words, not coming from the actual keyboard, from the hand of the user, but emulated with SendInput or SendMessage etc.
MSDN teaches you that GetAsyncKeyState gets the physical key state, but other answers say SendInput looks like a legitimate input to the target program.
Does SendInput affect GetAsyncKeyState? and If not, is it reliable to check the key state while processing the input queue, and discard non legit input by checking if the key is really down?
Related
We have a legacy application which uses a variety of individual key presses to perform certain functions. Now we want to add a barcode scanner, but if the input focus is not in the right place, that can lead to the barcode being interpreted as a set of individual commands, not a multi-character barcode.
My initial thought was to pause momentarily when the first char is available, then check how many chars are available in the input buffer, and treat the input as a barcode if there are multiple characters waiting. However, this doesn't work - std::cin.rdbuf()->in_avail() always returns zero:
Sleep( 50 );
const char ch( std::cin.get() );
std::cin.putback( ch );
if ( std::cin.rdbuf()->in_avail() >= 6 )
{
// code never reached :-(
}
The code above was inserted in the context of a PreTranslateMessage() override for a WN_KEYDOWN message. Could it be that the messages are not yet translated, and therefore std::cin has no access to the characters? If so, is it possible to determine how many WM_KEYDOWN messages are queued instead of how many characters? It's not obvious how to do that via the MFC and/or Win32 APIs.
First, a window program, if you don't call AllocConsole, has no stdin/stdout/stderr. And GetStdHandle(STD_INPUT_HANDLE) will always fail. So this method is not applicable.
You can make barcode scanner add prefixes and suffixes (some characters that not the same as your keyboard) that indicate the input is coming from the barcode scanner, rather than a standard keyboard. You can easily set up this with manuals or APIs provided by barcode scanner supplier.
Other non-recommended solutions:
Judge the interval between WM_KEYDOWN and WM_KEYUP.
Judge the interval between two keystrokes.
If it's slower, it's keybord input, else barcode scanner. (Not suitable for sending command through code simulation keyboard input)
I am curious how the user input is handled in micro-controllers in way that all other work is not blocked.
For instance, I have modern gas boiler - Vaillant, boiler is running his own tasks while I can scroll in the user menu, press buttons and so on.
How this is worked out from conceptual point of view?
Is there another micro-controller which handles user input and then it pushes selected inputs to main controller?
Or there is just some type of scheduller in main controller and it is scheduling so fast so it can handle user inputs AND background tasks?
How this is handled in general so user can play around with menu and so on without blocking the main task.
Thank You
This can be handled in many different ways and, depending on the complexity of the overall application, it can be as simple as a super-loop, or as complex as a multitasking based application with several independent tasks each doing their own thing (e.g., one doing key press detection, another dealing with serial comms, another updating the [G]LCD, etc.).
Your particular example can easily be handled with the super-loop approach, although a multitasker can also be used for (IMO) simplicity in coding.
For example, with the super-loop approach, each time through the loop you call a key press detection routine which checks if a key is pressed and counts time up to some maximum as long as the key press is still present. It does not block, it exits immediately. When the count reaches a minimum to accept the key (e.g., corresponding to about 50-100 msec) you return the key pressed and zero the counter (for auto key repeat), or save the key in a temporary buffer and return it only when the key is eventually released (if no auto key repeat is desired).
The display works in a similar way. The current screen is updated depending on which state the device is in. When the UP/DOWN key (for example) is detected, the index of the scrolling item changes up or down and the screen is redrawn with the new state.
There are certain situations that a multitasker is the only reasonable way to solve such problems if you don't want your app to become a un-debuggable mess of flags, and ifs. Dealing concurrently (and smoothly) with multiple interfaces (e.g., GPS, GSM, user terminal, key/LCD) is one such example.
BTW, interrupts for key presses are IMO an overkill unless you are in some battery saving sleep mode and need a hardware way to wake up. Human key presses are always too slow by comparison to CPU speeds and can be detected reliably by simple polling.
Most CPUs have some form of interrupts (even the PC).
Basically the interrupt tells the CPU to stop what it is doing and handle some realtime event. When the interrupt handler is complete the CPU will resume its original program.
More detailed information on interrupts is available on wikipedia
So the problem at hand is pretty much the following:
Windows key repeat settings affecting Raw Input messages
Although this might be a duplicate then, there is no answer provided, so here it goes:
I am under the impression that e.g. for FPS game development, one should use raw input. The problem then however, is that the input is not so raw after all and includes a delay (for a continuous keydown) and only after that initial delay a continuous key press, that is continuous flow of WM_INPUT messages. When using DirectInput (which is deprecated), I do not have those problems. Is there a way to achieve the same thing using only raw input? To be clear, what I want is that, if I press a key continuously, I continuously get WM_INPUT messages without the initial delay caused by autorepeat.
I am using the raw input standard read, not the buffered one (https://msdn.microsoft.com/en-us/library/windows/desktop/ms645546(v=vs.85).aspx)
Where is the difference between the aforementioned standard raw input reading and the buffered one?
DirectInput is an outdated, async abstraction layer, that does exactly the same thing: processes raw input. It is not recommended to use it unless you need to support joystick or anything legacy, for gamepads XInput is being recommended.
Windows is not a real time OS, the best option is to stick to WM_INPUT messages. This requires maintaining an array of key states (bool keyState[256]) and basing your logic as if(keyState[VK_BACKSPACE] == true){}.
If you want to also catch the press start and release events, you will have to maintain an array of last key state, and analyzing WM_INPUT check for the change, and produce the press start event only if last state of key was false and WM_INPUT message says key is pressed now.
The other option is to use GetAsyncKeyState to manually check all the input regularly. But that will leave you without the ability to catch key press if it happened between your two calls for GetAsyncKeyState. The documentation of the function says that the lower bit tells exactly that, but that bit is shared among all applications and can be reset by other app, which is sad.
If I understand you correctly, what you want is just the momentary key state, which can be easily obtained through helper classes like Keyboard, it does not use WM_INPUT though, so a minor latency may occur due to window check layer.
auto kb = keyboard->GetState();
if (kb.Back)
// Backspace key is down, with no delay of waiting for key repeat
I have a C++ program that takes input from the user on std::cin. At some points it needs to call a function that opens a GUI window with which the user can interact. While this window is open, my application is blocked. I noticed that if the user types anything into my application's window while the other window is open, then nothing happens immediately, but when control returns to my application those keystrokes are all acted upon at once. This is not desirable. I would like for all keystrokes entered while the application is blocked to be ignored; alternatively, a way to discard them all upon the application regaining control, but retaining the capability to react to keystrokes that occur after that.
There are various questions on Stack Overflow that explain how to clear a line of input, but as far as I can tell they tend to assume things like "the unwanted input only lasts until the next newline character". In this case this might not be so, because the user could press enter several times while the application is blocked. I have tried a variety of methods (getline(), get(), readsome(), ...) but they generally seem not to detect when cin is temporarily exhausted. Rather, they wait for the user to continue supplying content for cin. For example, if I use cin.ignore(n), then not only is everything typed while the GUI window was open ignored, but the program keeps waiting afterwards while the user types content until a total of n characters have been typed. That's not what I want - I want to ignore characters based on where in time they occurred, not where in the input stream they occur.
What is the idiom for "exhaust everything that's in cin right now, but then stop looking for more stuff"? I don't know what to search for to solve this.
I saw this question, which might be similar and has an answer, but the answer asks for the use of <termios.h>, which isn't available on Windows.
There is no portable way to achieve what you are trying to do. You basically need to set the input stream to non-blocking state and keep reading as long as there are any characters.
get() and getline() will just block until there is enough input to satisfy the request. readsome() only deals with the stream's internal buffer and is only use to non-blockingly extract what was already read from the streams internal buffer.
On POSIX systems you'd just set the O_NONBLOCK with fcntl() and keep read()ing from file descriptor 0 until the read returns a value <= 0 (if it is less than 0 there was an error; otherwise there is no input). Since the OS normally buffers input on a console, you'd also need to set the stream to non-canonical mode (using tcsetattr()). Once you are done you'd probably restore the original settings.
How to something similar on non-POSIX systems I don't know.
ToUnicodeEx:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646322(v=vs.85).aspx
ToUnicode:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646320(v=vs.85).aspx
It seems that the only difference between the two is that ToUnicodeEx allows the passing of the input locale indentifier parameter as ToUnicode does not.
My question is: Does ToUnicode itself call ToUnicodeEx?
Also, at the bottom of the ToUnicodeEx msdn page, in the remarks section, we see:
As ToUnicodeEx translates the virtual-key code, it also changes the state of the kernel-mode keyboard buffer. This state-change affects dead keys, ligatures, alt+numpad key entry, and so on. It might also cause undesired side-effects if used in conjunction with TranslateMessage (which also changes the state of the kernel-mode keyboard buffer).
Does anyone know exactly what it is doing the kernel-mode kb buffer?
ToUnicode and ToUnicodeEx are both wrappers around NtUserToUnicodeEx and yes, the only difference is the final parameter which is NULL for ToUnicode and user-supplied for ToUnicodeEx.
Because dead keys are used to generate characters from multiple separate key presses the OS has to keep a history of which dead keys were previously pressed. I think all that note is warning you is that ToUnicodeEx and TranslateMessage both use the same history - so mixing calls to the two functions could generate unreliable results.