I need to detect a keypress in a console application, without prompting the user. Basically, my app is normally a daemon that listens to a special input device, but i need to simulate it on a dev box using the keyboard in interactive mode. How can I do this? - Im on a Linux system.
If you can't block while waiting for input, then you can use e.g. select to check if the STDIN_FILENO file descriptor is ready for reading, and if it is then you can use normal input functions (scanf, fgets std::getline, etc.).
You check this answer which explains how to read from the input events ( usually /dev/input/event0)
Or directly check the answer's source :
Credits do not go to me, this code is taken from the Ventriloctrl hack to get keystrokes.
http://public.callutheran.edu/~abarker/ventriloctrl-0.4.tar.gz
This text explaines hw to do such a thing. http://thc.org/papers/writing-linux-kernel-keylogger.txt
Related
Let's say I was using cin in my program to allow the user to input into the console. That is simple enough but what if they were typing into, let's say, a web browser and I wanted them to input that into the console at the same time? When I click away the C++ program console window and have something else on top, the input obviously does not go into the console. How can I make it so the console is always running on top so that even when I were to input something into a web browser, it would also go into the console?
in order capture keyboard input when your application is not focused, you need to use windows hook, see:
http://msdn.microsoft.com/en-us/library/ms644959%28v=vs.85%29.aspx#wh_keyboardhook
Example code can be found here:
http://www.codeguru.com/cpp/w-p/system/keyboard/article.php/c5699/Hooking-the-Keyboard.htm
I think you may want to take a look at hooking the keyboard to get the input?
I have a C++ console application that prints some output constantly while it also accepts commands (using std::cin) from the user - output and input happen in separate threads.
If I write a text while some output appears the written text is mixed with application output. How can I prevent this behaviour?
To solve this problem, I need to display the program one line above the line where the text is typed. I'd inspire myself in Minecraft Bukkit server's solution - however I need the same for C++.
Assuming you want the output to appear while things are being typed, you'll need some screen control facilities to have the output go somewhere different than the input area. If I were tasked to implement something like this writing to a terminal I would refresh my ncurses experience. I realize you are on a Windows console and I have no idea if the Windows console is capable of the screen control needed to make it happen.
You can possibly tie custom stream buffers into std::cin and std::cout using the curses functionality under the hood but it may not be worth it. In any case, it isn't entirely trivial.
There's a windows port of ncurses called pdcurses. But if you are using visual studio there's a simple function provided called SetConsoleCursorPosition()
I want to make a version of cin that works in a graphics display window (it's SDL, but I don't think that matters here): that is, when you type, the characters echo into that window rather than the console window. The solution should be cross-platform.
I have this page to tell me how to get characters NOT to echo to the console window: Reading a password from std::cin
...but what I don't know how to do is to make the characters echo on the new graphics display window.
One thing I could do is intercept keyboard events, and if one happens, print the character. But this wouldn't perfectly echo the actual behavior of the istream buffer, because of repeating keys, backspace, enter, tab, and also the real behavior of cin in that if you are typing before C++ gets to the cin, it will put that stuff you typed on the screen at that point.
I think this echoing is done inside the call to _read (read in the Unix world), and that I'm not sure how to access.
TIA.
The behaviors you're talking about are not done by cin nor read() syscall; buffering and processing of special character is done by the terminal emulator and the shell.
You do need to intercept key events and implement these yourself. Alternatively, some terminal emulators (e.g. VTE widget in Gnome) were designed so they can be embedded into another program. You might want to look at that option.
Considering your application is running in a window you shouldn't read input from the console . It's probably possible but you'll have to switch to the terminal window from where you started the window each time you want to input text. If you take this route you need to disable tty echo: http://man7.org/tlpi/code/online/dist/tty/no_echo.c.html (for Linux). Check out http://www.cplusplus.com/forum/general/12256/ for some solutions for Windows too. I don't think there is a solution that works for both so you'll need to bury some #ifdef's in some utility functions.
Since you're using SDL you should probably use SDL's input functions.
Check out http://www.libsdl.org/docs/html/guideinputkeyboard.html
And, more specific to your needs: http://wiki.libsdl.org/moin.fcg/Tutorials/TextInput
I'm writing a console application in which user interaction might be necessary (prompt for keyboard input, cli arguments etc.), but I want to keep it separate from the result of the processing (which goes to cout, in a way that it can be piped to some other application).
How can I achieve this, if I can't just send all interaction with the user to cerr (not everything is an error)?
/dev/tty is the usual way, but it's also possible on most Unix-like operating systems to read from cerr/stderr because the system usually opens the tty once as stdin and dup()s it onto stdout and stderr.
When your stdout is piped somewhere else, the only way to show something on the terminal (apart from maybe things like curses and dialog) is stderr.
If you need user interaction, open /dev/tty, it will be the controlling terminal for the process. Standard error and standard input may be redirected as well.
I have a problem with my application win32 console.
The console is used to give commands to my application. However, at the same time it is used to output log messages which mostly comes from asynchronous threads. This becomes a problem when the user tries to write some input and simultaneously an async log message is printed, thus thrashing the display of the users input.
I would like to have some advice in regards to how to handle such a situtation?
Is it possible for example to dedicate the last line in the console to input, similarly to how it looks in the in-game consoles for some games?
You can use SetConsoleMode to disable input echo and line editing mode. You can then echo back input whenever your program is ready to do so. Note that this means you will need to implement things like backspace manually. And don't forget to reset the mode back when you're done with the console!
This is possible using the Console API, but it involves quite a bit of work and all the threads that use the console will have to cooperate by calling your output method rather than directly calling the Console API functions or the runtime library output functions.
The basic idea is to have your common output function write to the console screen buffer, and scroll the buffer in code rather than letting the text flow onto the last line and scroll automatically. As I recall, you'll have to parse the output for newlines and other control characters, and handle them correctly.
You might be able to get away with using "cooked" console input on the last line, although in doing so you risk problems if the user enters more text than will fit on a single line. Also, the user hitting Enter at the end of the line might cause it to scroll up. Probably best in this situation to use raw console input.
You'll want to become very familiar with Windows consoles.
Any time you have asyncronous threads trying to update the same device at once, you are going to have issues like this unless something synchronizes them.
If you have access to everyone's source code, the thing to do would probably be to create some kind of sync object that every task must use to access the console (semaphore, etc).