If you were to have looked in the Commonly Asked C/C++ Questions
sticky thread (meaning that it's always there at the top), then you would have found your question to be the third one listed. It points to a 2004 message with answers and a bit of discussion at http://forums.devshed.com/c-program...nds-157960.html
. For example, your solution of running PAUSE would work on a Windows platform, but undoubtedly not on Linux and who knows about Macs.
You already found that if you run your program as it was originally intended to be run -- namely from the command line -- that it works just fine. The problem is when you try to run it from a GUI. The reason is that the program is intended to run in a shell (on Windows AKA "console", AKA "DOS window"). When you run it from the command line, you're already in a shell so it works just fine.
But if you're running a GUI app (eg, Windows Explorer) that then launches your program, part of that process is to create a shell for the program to run in. But then when your program terminates, the shell closes automatically, which creates the problem of the output going away before you can read it.
The solution is to find some method to keep the shell from closing until you are ready to let it close. These methods can include:
1. Just before exiting the program, add a request for user input. system("PAUSE") is one possibility, though it's OS-dependent. getchar() is another, as is scanf, but you can experience other problems because of characters left over in the input buffer.
These methods all fall under the heading of "KLUDGE
". They are jury-rigged, quick-and-dirty, inelegant, and clumsy quick fixes. They are aesthetically displeasing.
2. Write a proper command-line app. Such as a program with a menu of actions that you can choose from, one of which is to exit the program (AKA "quit"). At the very least, prompt your user to enter a command to quit, even it involves pressing the "any key".
3. Research into finding a setting for your shells to not close automatically. There does appear to be a way to do this, as I've witnessed certain IDEs using this approach.
4. Run it from the command line as it was intended to be run.
If you go with the kludge in #1 or even with #2, you need to know how to read input. The answers you got at first alluded to a problem you would have with scanf("%c,&ch).
When you call scanf, it reads what's in the input buffer and converts it as you specify in the format string. But since C programs were originally run from terminals, many of which were line-oriented, the program doesn't recognize any input until you've hit the Enter key. scanf then scans and converts the input as per the format string and when it's done it stops, leaving any unconverted characters in the input buffer. The next scanf starts from there, converting what it can and/or waiting for the next line of input to continue. Hence you could have typed all four of your input values on one line and the four successive scanf's would have read them all in correctly.
scanf normally skips white space, which includes newlines, but %c is different. If you write scanf("%c",&ch), then scanf would read in the next character regardless of what it is, even white space. So if the next character in the input buffer were the newline character(s) from the Enter key, then that would be read in and scanf would be satisfied. That would cause a common complaint we receive of the program just blowing right past the scanf.
The solution to that would be to tell scanf to expect and skip any white space that may precede that character, thus skipping the newline from the last scanf. That would be written thus:
scanf(" %c", &ch);
This was the leading space that the others were telling you about, though I am sure that it's not necessary for their examples (doesn't do any harm, but still not needed). It is needed when dealing with %c .
Please note that scanf(" %c", &ch) requires a printable character to satisfy scanf. Hitting the space bar simply will not work, since a space is white space and will be skipped by scanf.
Please also note that getchar will create the same problem as scanf("%c",&ch).