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
Related
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
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?
Ok, so I created a really simple SendText Function
void SendText(string str)
{
for (std::string::iterator it = str.begin(); it != str.end(); ++it)
{
PostMessage(h, WM_KEYDOWN, VkKeyScan(*it), 0);
}
return;
}
The problem is pretty apparent, but the workaround is not. If send the string
Hello World!
The outputted text is "hello world1"...
However, the way this app handles my messages, I'm unable to simply check if shift needs to be held and send VK_SHIFT messages. Basically, the app doesn't handle KEYDOWN and KEYUP messages, it simply treats them as keypressed events.
So it turns into Shift Pressed / Released ..... Key Pressed / Released ... Shift Pressed / Released.
The GOAL:
To somehow use a single postmessage to send the correct shifted or unshifted character to the app. Or possibly maybe other ideas as to why the keydown/keyups are just translated to keypressed. And it must be able to be handled in the background (ala no send input)
As mentioned in comments, your project is likely not Unicode.
Taken this out of one of my projects, sending keys should now work.
Permalink
Please take note, that I have encountered issues with sending strings - whole text messages - as the window may not (be able to) handle them as fast as you send them. A small delay between the keys can fix this issue. In my project I have a thread for sending texts, using a std::queue (with mutex...) to work through all texts. Therefore a short call to Sleep wouldn't be too wrong, in case you have a thread for this.
You can try different delays, also always depending on your computer. Older operating systems or older computers may be slower and need a higher delay. You could either add checks for the OS/specs, or an option to user-define the delay between the characters of your text.
If anyone has a direct solution to send Shift to a background window, feel free to leave a comment and I will edit my answer.
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.
I'm coming from C and don't have too much programming knowledge, so bear with me if my idea is nonsense.
Right now, I'm trying to write a simple threaded application with double-buffered console output. I've got a thread which resets the cursor position, draws the buffer and then waits n milliseconds:
gotoxy(0, 0);
std::cout << *draw_buffer;
std::this_thread::sleep_for(std::chrono::milliseconds(33));
This works perfectly well. The buffer is filled independently by another thread and also causes no problems.
Now I want the user to be able to feed the application information. However, my drawing thread always puts the cursor back to the start, so the user input and the application output will interfere. I'm aware there are libraries like curses, but I'd prefer to write this myself, if possible. Unfortunately, I haven't found any solution to this. I guess there is no way to have two console cursors moving independently? How else could I approach this problem?
I think what you will need to do two things:
Create a mutex that controls which thread is writing to stdout.
Change the input mode so that when you invoke getchar, it returns immediately (rather than waiting for the user to press enter). You can then wait for the other thread to release the mutex, then move the cursor and echo the character the user pressed at the appropriate part of the screen.
You can change the input mode using tcsetattr, although this is from termios which is for *nix systems. Since you're using windows, this may not work for you unless you're using cygwin.
maybe check this out: What is the Windows equivalent to the capabilities defined in sys/select.h and termios.h