reading stdin for key presses vs a redirected file

[TazDev]

I'm trying to write a console program to exactly duplicate a much older dos-based program.

This older program uses getch() to prompt a user for a response to a question. This program is also used in batch files where a file containing just the response would be redirected into the program so it wouldn't wait for user input.

For example: program.exe < input.txt

It seems as though redirected files don't act the same as user input in a console program even though I expected them both to go through stdin. Getch() doesn't work with redirected files in a console program like in the above example.

I've had success using cin and also with CreateFile with CONIN$ as the input name, to handle keypresses as well as redirected files. However, when handling user keypresses, both alternatives require a carriage return before the input is processed, whereas the original program using getch() only required the keypress - no carriage return necessary.

Is there any Win32 equivalent to the getch() command or some workaround that would work with user keypresses as well as redirected input?

Thanks.
Taz

[weaknessforcats]

getch() reads a character directly from the keyboard.

getchar() reads a character from the console.

I suspect if you use getchar() instead of getch() then your problem with redirected input will disappear.

[TazDev]

Thank you for your suggestion. "getchar()" does work with both, but requires the user to hit return before processing.

I'm currently playing around with PeekNamedPipe in conjunction with CreateFile using CONIN$ to see if I can get something going.

If you have any other ideas, let me know!

[weaknessforcats]

I understand. But the enter key could be in your input file right?

Otherwise, you will ned to write the program to use an actual file.

[TazDev]

I meant when a user is in control, they still need to press enter. That's the main sticking point now.

It actually doesn't matter whether you have a carriage return in the file or not. It still gets processed.

I've got something that seems to work. It's not pretty but I can't figure out another way of doing this. Basically I check to see if there's anything in stdin. If there is I use whatever function I want to get it, otherwise I use getch().

Thanks for the help though.

BOOL check_stdin ()
{
	fpos_t pos;

	fgetpos (stdin, &pos);
	++pos;
	if (fsetpos (stdin, &pos))
		return FALSE;
	else
	{
		rewind (stdin);
		return TRUE;
	}
}
main ()
{
	if (!check_stdin ())
	{
		// use getch ();
	}
	else
	{
		// use fgets or whatever
	}
}

[weaknessforcats]

I meant when a user is in control, they still need to press enter. That's the main sticking point now.

That's the way it works. The user turns control back to the program by pressing enter.

There is no other way to tell of the user is done making input. Even then, when your program resumes, you have no idea what was entered. A robust input edit will be a very time consuming and complicated thing to write. I tell students to use "friendly" input. That is, enter what is expected. Use that to get the program working. When that's done you go back and add input edits. Don 't be surprised of the input edit code is larger than the program was in the first place.

Then there's other stuff, like EOF (the same as CTRL+Z) which indicates end-of-all-input. When the user enters CTRL+Z and you pick up on that to mean all input is done, there is still the enter key used to enter CTRL+Z in stdin waiting top trip you up.

I still an uncertain why a file can't work for you. When you press enter to record a line in the file, that enter will be fetched just like the user pressed the key.

Your only other option is to write your own keyboard driver functions and use them instead of the standard ones supplied with C. That's what Windows does.