I want to add something to the user input buffer using ncurses (basically, the typeahead, before the user presses enter). I know there is a function flushinp(), which allows for clearing of the input buffer. Is there also a function that allows for me to add something to the buffer? My ultimate goal is to have command completion upon a press of the tab key.
You can put (subject to an implementation-defined limit of) characters into the input queue using ungetch or unget_wch.
These are both in X/Open Curses, so they're reasonably portable. X/Open only guarantees a single character, however:
ungetch, unget_wch - push a character onto the input queue
The coverage of curses functions in Python's binding is incomplete; it documents only ungetch.
Related
(in Linux)
The methods I found all use signal .
Is there no other way? Is there anything I can do to make the terminal put it into the input buffer?
In order to "read CTL+C as input" instead of having it generate a SIGINT it is necessary to use tcsetattr() to either clear cc_c[VINTR] or clear the ISIG flag as described in the manual page that I linked to, here.
You will need to use tcgetattr, first, to read the current terminal settings, adjust them accordingly, then tcsetattr to set them.
You should make sure that the terminal settings get reset to their original defaults when your program terminates, it is not a given that the shell will reset them to default, for you.
Nope, signal() is not the way. You should need to configure the tty driver to do raw input (no input char processing in the driver), so it passes all characters untouched. But this requires considering the tty input device as special and write special code to treat that case (this requires you to issue several ioctl system calls). But this is not recommended, for the reasons explained below.
Second, there's another, simpler way that doesn't require to use raw mode. You can escape the Ctrl-C character by prepending the tty escape character. In Linux and BSD system, this is normally tied to the Ctrl-V character, so pressing Ctrl-V + Ctrl-C allows you to input a single Ctrl-C char. I have just checked it with the hd command:
$ hd
^C
00000000 : 03 0a : ..
00000002
$ _
Next question is, then, how to input a Ctrl-V? well, just double it! (but we are out of scope now, just continue reading)
The advantage of this approach is that it doesn't require programming in your program and will work the same way when reading from a file, pipe, fifo, socket, etc. (to which Ctrl-C has no special meaning, as the tty driver is out of scene) The only device that generates an interrupt when detecting Ctrl-C is the tty driver (more exactly, the controlling tty, in it's code generic part, so all ttys do this) and it also has a escape character (by the same reason, all ttys have it) to invalidate the special meaning of the next character.
You can check which character is the escape character with the stty(1) command, configured as the lnext entry. But I can almost ensure you that it will be Ctrl-V.
Note
This also applies to any other special character (like Ctrl-D, Ctrl-H, etc. that the terminal uses for special purposes)
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 considering using QTextEdit as console-like IO element (for serial data).
The problem with this approach is that (user) input and (communication) output are mixed and they might not be synchronous.
To detect new user input, it might be possible to store and compare plainText on certain input events, e.g. when Enter/Return is pressed.
Another approach might be to use the QTextEdit as view only for separately managed input and output buffers. This could also simplify the problem of potentially asynchronous data (device sends characters while user is typing, very unlikely in my case).
However, even merging the two "streams" by single-character timestamp holds potential for conflict.
Is there a (simple) solution or should I simply use separate and completely independent input/output areas?
Separate I/O areas is the simplest way to proceed if your UI is command driven and the input is line-oriented.
Alternatively, the remote device can be providing the echo, without a local echo. The remote device will then echo the characters back when it makes sense, to maintain coherent display.
You can also display a local line editing buffer to provide user feedback in case the remote echo was delayed or unavailable. That buffer would be only for feedback and have no impact on other behavior of the terminal; all keystrokes would be immediately sent to the remote device.
There are two ways that I know to flush stdin:
(1) bool FlushConsoleInputBuffer(_In_ HANDLE hConsoleInput);
(2) fflush (stdin);
However, in my environment:
Compiler: MinGW g++
Running in: Windows, Cygwin xterm or Cygwin mintty
Neither of them works.
What can I do?
Note: FlushConsoleInputBuffer() works if my program runs under dos prompt window. In addition, FlushConsoleInputBuffer() nicely returns false, when it runs on Cygwin xterm or mintty.
--UPDATE--
I suspect that Cygwin handles stdin separately than Windows native stdin, which make FlushConsoleInputBuffer() fail.
#wallyk: yes. 'flush' means dropping all unread buffered inputs.
--UPDATE-- (final answer accepted and reason)
Tony D is right. The problem is that Cygwin terminal is a unix-like terminal, which allows editing before 'ENTER' key is hit. Thus any partial input must be buffered and will never be passed to stdin before the 'ENTER' key is hit, since it expects editing commands. I guess it should be possible to overcome this by setting terminal to raw mode (not experimented). Yet the editing feature will be lost in the raw mode.
fflush is meant to be used with an output stream. The behavior of fflush(stdin) is undefined. See http://en.cppreference.com/w/cpp/io/c/fflush.
If you use std::cin to access stdin, you can use std::istream::ignore() to ignore the contents of the stream up to a given number of characters or a given character.
Example:
// Ignore the rest of the line.
std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
Working code: http://ideone.com/Z6zLue
If you are using stdin to access the input stream, you can use the following to ignore the rest of the line.
while ( (c = fgetc(stdin)) != '\n' && c != EOF);
Working code: http://ideone.com/gg0Az2
Discarding exactly and only the data currently buffered/available to stdin isn't supported using only C++ Standard library features.
Most of the time, programmers just ignore (see example at the bottom of that page) the rest of a problematic line then try the next buffered line. If you're concerned there may be a lot of problematic lines - for example, that the user may have cut-and-pasted pages of nonsense that you want to discard, but then you do want to give them a chance to enter further lines, you need to use an OS-specific function to work out when a read on stdin would block. You'd then ignore lines until that would-block condition is true.
select and poll are two such operations that work on most Operating Systems, but from memory they're only defined for socket streams on Windows so of no use to you. Cygwin may or may not support them somehow; if you want to try it - you would ignore lines as long as the stdin file descriptor (which is 0) tests readable. You'll find lots of other Q&A discussing how to see if there's input available: e.g. checking data availability before calling std::getline, Check if stdin is empty, Win32 - read from stdin with timeout
Keep in mind that your terminal program is probably internally buffering what you type until you press ENTER, so at most your program can clear the earlier lines but not a line the user's partially typed (though you could use some heuristic to discard it after it's sent to your program's stdin).
UPDATE
Cruder alternatives that might be good enough in some circumstances:
save the now() time, then loop calling getline(std::cin, my_string) until either it fails (e.g. EOF on stdin) or the time between reads is greater than some threshold - say half a second; that way it's likely to consume the already-buffered but unwanted input, and yet ENTER for further hand-typed user input's likely to happen after the discarding loop's terminated: you could prompt ala std::cout >> "bad input discarded - you may press ^U to clear your input buffer if it contains unwanted text...\n"; (Control-U works for many terminals, but check your own)
have a particular string like say "--reset--" that the user knows they can type to stop discarding lines and switch back to processing future lines
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.