Pausing screen?

[Zach]

When I compile a C program in Dev-C++ (www.bloodshed.net) or in
Microsoft Visual Studio 8 Express it will flash a DOS window with the
results and then immediately close! How can I pause the screen?

Zach

 

[Dr Malcolm McLean]

When I compile a C program in Dev-C++ (www.bloodshed.net) or in
Microsoft Visual Studio 8 Express it will flash a DOS window with the
results and then immediately close! How can I pause the screen?

There are several options.
The best one is to dig into the gubbins of your compiler and find how
to switch this behaviour off. I think there's a way but I've
forogotten it.
Another way is to put a
while(1); (note semicolon) at the end of your main(). This will hange
the program until you kill it with a control-C.
Another way is to put in
#include <conio.h>
getch();

This is slightly nicer, and will wait for a keypress, but is non-
standard.

 

[Bill Reid]

When I compile a C program in Dev-C++ (www.bloodshed.net) or in

There are several options.
The best one is to dig into the gubbins of your compiler and find how
to switch this behaviour off.
Doubtful, doc...

I think there's a way but I've
forogotten it.

You can't forget something you never knew...

Another way is to put a
while(1); (note semicolon) at the end of your main(). This will hange
the program until you kill it with a control-C.
Dumb idea...

Another way is to put in
#include <conio.h>
getch();

This is slightly nicer, and will wait for a keypress,  but is non-
standard.

Another dumb one...but on a better track, you can
use a standard function call for getting command-line
input to "pause" the program until RETURN is pressed
(guess which function we can use?)...

However, the real issue is that under Windows(TM),
the program is run as a "console" program, which
causes a "console" to be created automatically for
program input/output, and then the "console"
disappears when it is no longer needed at the
exit of the program.

But guess what, you can run the program from a
MS-DOS window that you bring up by running the
"command prompt" program or whatever Microslop
is calling it these days. In that case, the
MS-DOS window will not disappear when the program
completes.

So there's the correct answer (both of them)...

 

[Keith Thompson]

There are several options.
The best one is to dig into the gubbins of your compiler and find how
to switch this behaviour off. I think there's a way but I've
forogotten it.

[...]

There's likely to be an option in the IDE (not in the compiler) to
keep the DOS window open after the program terminates, or perhaps
to direct the program's output to a window within the IDE itself.

 

[Bill Reid]

There are several options.
The best one is to dig into the gubbins of your compiler and find how
to switch this behaviour off. I think there's a way but I've
forogotten it.

[...]

There's likely to be an option in the IDE (not in the compiler) to
keep the DOS window open after the program terminates, or perhaps
to direct the program's output to a window within the IDE itself.

Hmmmm, kind of like the dumb leading the dumber...

Unless MICROSOFT provides such an option for their
"CONSOLE" (which, to the very best of my knowledge,
they DON'T), no IDE/compiler/whatever can change the
behavior...

This is equivalent to writing a Windows(TM) app
and asking if you can make the window oval instead
of rectangular, then people "advising" that the
IDE/compiler will "probably" have an option to do
that...

 

[Ian Collins]

When I compile a C program in Dev-C++ (www.bloodshed.net) or in
Microsoft Visual Studio 8 Express it will flash a DOS window with the
results and then immediately close! How can I pause the screen?

Avoid windows?

 

[Peter Nilsson]

Another dumb one...but on a better track, you can
use a standard function call for getting command-line
input to "pause" the program until RETURN is pressed
(guess which function we can use?)...

The problem with this is that many student programs use
scanf and there's often a trailing newline from the last
input that gets swallowed by a getchar. And so the program
disappears in a flash, just as before... [This is probably
a source of many 'how do I flush stdin?' questions.]

 

[Bill Reid]

More "contributions" from the brain trust that is comp.lang.c:

If you're running in debug mode, simply set a breakpoint on main's
return statement.

Hmmmm, probably will work as advertised, I'll give that one...

If you're running in release mode, VStudio already retains the console
window until you press a key, so you don't get the problem in the first
place.

Too bad the original message said he was using "Visual Studio 8
Express" so it appears you don't know how it works but that didn't
stop you from posting...

If you're running from the console, you still don't get the problem in
the first place.

Here is everything you didn't want to know or are too
technically incompetent to understand about Windows "consoles":

http://msdn.microsoft.com/en-us/library/ms682010(VS.85).aspx

If you drill down you'll find that there is very clear
rule that THE CONSOLE TERMINATES WHEN THE PROGRAM THAT
LAUNCHED THE CONSOLE EXITS.

You are thinking of a separate program called the
"MS-DOS Command Prompt" or sumpin' that causes Windows
to create a console for IT, and any program you run in
it uses THAT program's console, so the console only
terminates when THAT program exits.

Given the above options, putting a "press me to quit" into your program
is simply daft, so don't do it.

No, not necessarily, since you don't know how the program
will be launched or exited, but you know (well, not you,
apparently) that you will get a warning from some versions
of Windows about trying to exit the program using the CONSOLE
exit control (something about "it is recommended that this
program be terminated from within the program and not from
the console").

If you *do* do it, you'll regret it when
you release your code - either you'll take it out, in which case you'll
be forever putting it in and taking it out whenever you have to maintain
the code, or you'll leave it in, in which case your users will curse
your name every time they try to use your program as a filter.

"Interactive" is just another word for "manual". Don't give the user
extra work.

Since some versions of Windows will give them a confusing
warning if they launch the program anywhere but from the
command line, you might want to take THAT into consideration...

 

[Bill Reid]

Another dumb one...but on a better track, you can
use a standard function call for getting command-line
input to "pause" the program until RETURN is pressed
(guess which function we can use?)...

The problem with this is that many student programs use
scanf and there's often a trailing newline from the last
input that gets swallowed by a getchar. And so the program
disappears in a flash, just as before... [This is probably
a source of many 'how do I flush stdin?' questions.]

Yes, so we can eliminate getchar() or getc() or
similar as we "guess" which function to use...

 

[Ian Collins]

Since some versions of Windows will give them a confusing
warning if they launch the program anywhere but from the
command line, you might want to take THAT into consideration...

Another reason to avid windows.

 

[123Jim]

When I compile a C program in Dev-C++ (www.bloodshed.net) or in
Microsoft Visual Studio 8 Express it will flash a DOS window with the
results and then immediately close! How can I pause the screen?

Zach

Assuming windows? ...

#include <stdio.h>

int main()
{
/* some program code*/
system("pause");
return 0;
}

 

[Zach]

If you're running in debug mode, simply set a breakpoint on main's
return statement. If you're wise enough to follow the one-entry one-exit
rule every time (i.e. don't have any exit() calls), this will work every
time - except in the case of an assertion, but that's okay because if
you get an assertion failure the IDE is already pretty good at getting
you the information you need.

If you're running in release mode, VStudio already retains the console
window until you press a key, so you don't get the problem in the first
place.

If you're running from the console, you still don't get the problem in
the first place.

Given the above options, putting a "press me to quit" into your program
is simply daft, so don't do it. If you *do* do it, you'll regret it when
you release your code - either you'll take it out, in which case you'll
be forever putting it in and taking it out whenever you have to maintain
the code, or you'll leave it in, in which case your users will curse
your name every time they try to use your program as a filter.

"Interactive" is just another word for "manual". Don't give the user
extra work.

Thanks Richard and everyone who helped me with this problem.

Zach

 

[Bill Reid]

Use the Debug menu, and click "Start without debugging". That's been a
feature of VS since forever, and it was retained in VSE.

It appears you don't know how to do that, but that didn't stop you from
posting.

I don't use that IDE, but I'm skeptical that the "release
mode" works the way you describe, since it wouldn't be a true
representation of how the code would actually work in real
life. In "real life" (Microslop "reality"), launching a
console application in any way other than from the "MS-DOS
Prompt" "console" causes Windows to create a console for
the application, and the console terminates when the
application exits (which makes a kind of twisted sense,
since why would you need a console solely for a single
program's input/output, then leave it there doing nothing
when the program exits?).

If you read my post again, you'll find that there is very clear text to
the effect that "If you're running from the console", suggesting to all
but the densest amongst us that you start a console and then run your
program from within that console.


No, I'm thinking of the right answer.

Nope, you're an idiot who doesn't know what he's talking
about. You keep slinging terms around like "console" without
knowing what they are, even after I provided a link to clear
documentation in plain English describing them...please
tell the entire class how you "start a console" OTHER
than starting the "MS-DOS Command Prompt" as I described
(hint: it's fully described in the documentation I provided
but absolutely doesn't solve the "problem")...

You, on the other hand, are not
thinking. I suggest you start.

<nonsense snipped>

You know, just snipping out the truth doesn't make
it go away, any more than burning a book deletes the
information it provided from the minds of the people
who read it...

 

[jacob navia]

Bill Reid a écrit :

In "real life" (Microslop "reality"),

The name of the company is Microsoft.

Nope, you're an idiot who doesn't know what he's talking
about.

One of the characteristics of the people that write things like
"Microslop" above, is that anyone that disagrees is an idiot, a
Microsoft slave, or whatever. Only THEY have the truth. All others
are stupids.

You keep slinging terms around like "console" without
knowing what they are, even after I provided a link to clear
documentation in plain English describing them...please
tell the entire class how you "start a console" OTHER
than starting the "MS-DOS Command Prompt" as I described

There is no "MS-DOS command prompt" since windows-95 -and
windows98- are no longer supported since several years.
Maybe it is YOU that do not know what you are talking about?

Other ways to open a console are:

(1) system("cmd");
(2) AllocConsole()
(3) AttachConsole()


Conclusion:
Do not throw insults around.

This is valid in many circumstances other than in this
forum.

 

[Bill Reid]

Bill Reid a écrit :


The name of the company is Microsoft.

I stand by my insult as a victim of Bill Gates' shenanigans
masquerading as "software"...

One of the characteristics of the people that write things like
"Microslop" above, is that anyone that disagrees is an idiot, a
Microsoft slave, or whatever. Only THEY have the truth. All others
are stupids.

Actually, that's the attitude of Microslop engineers...I
was having no end of problems using one of their applications,
so in a desperate Google(TM) to find solutions, I came
across the "blog" of the lead engineer for the program.

In short, he blamed the users for being stupid as to
how they used the program, and then went on with a big
sob story about how freakin' difficult it was to draw
bitmaps under Windows and that's why his software was
so crappy and they had so much other stuff to do yadda
yadda yadda...standard bad engineer crybaby wailings...

Problem is, the software he couldn't write properly
has been written dozens of times by other programmers,
and it works flawlessly like magic, for example, in the
little box sitting on my shelf to my right made in
Bulgaria that I paid $11 for, or the little USB plug-in
I paid $35 for (well, that's the price of the software
I actually use and the related hardware).

So don't you think it's fair to criticize somebody
for miserably failing to do something that others can
do in their sleep? I'd agree with your rant about
calling people "stupid" if I couldn't point to a
whole bunch of people who are demonstrably smarter...it's
all RELATIVE, innit?

There is no "MS-DOS command prompt" since windows-95 -and
windows98- are no longer supported since several years.

I originally stated that they've changed the name of
the "Command Prompt" over the years...a wilted rose by
any other name, eh?

Maybe it is YOU that do not know what you are talking about?

Nope. Learn to read.

Other ways to open a console are:

(1) system("cmd");
(2) AllocConsole()
(3) AttachConsole()

Well, good for you, but then what? What's your
point?

Conclusion:
Do not throw insults around.

OK, everybody else in the world first...

This is valid in many circumstances other than in this
forum.

Yes, the world would be a better place if unwarranted
derogatory remarks did not occur, that's why I always
get irked when some bad programmer blames his bad
programming on "user error"...

Oh, just to stir another pot a little, that bad
programmer who works for Microslop is, as you could
probably presume, the most academically qualified
engineer in the friggin' world, with like multiple
Masters in Engineering from MIT and what not, like
virtually all Microslop engineers, and you'd better
believe if he was backed into a corner over his
blatant incompetence, he'd pull out his academic
"accomplishments" as his final secret weapon to
thwart legitimate criticism of his "work", just
like "spin-nosey"...

 

[Bill Reid]

On 3/28/2010 4:03 PM, Bill Reid wrote:
[...]

Hmmmm, kind of like the dumb leading the dumber...

Unless MICROSOFT provides such an option for their
"CONSOLE" (which, to the very best of my knowledge,
they DON'T), no IDE/compiler/whatever can change the
behavior...

Then how do you explain the fact that when I run a program in Visual Studio
2005 and 2008 in non-debug mode, and I get "Press any key to continue . . ."
displayed in the console window?  (Same thing for VS6, as I recall.)

Although it's not an available option (AFAIK) in VS2005 and 2008, there's
nothing stopping the IDE from doing the same thing when debugging the program.

Yes, it would be possible for any IDE to create a
special console for a "character mode" application,
that just raises the question: what happens when you
run the application outside of the IDE? Does it
behave the way you want, or the users think it
should?

Not quite.  The IDE giveth the console window, and the IDE taketh it away.

Right. And if there is no IDE to giveth the console,
then the operating system will giveth it, and taketh
it away on program exit, even if there is some text
the programmer wanted the user to read and perhaps
study, copy, whatever...in those cases, the programmer
will want to implement his own user-controlled exit
routine. Simple enough, riiiiiight?

 

[Bill Reid]

Bill Reid a écrit : [...]
Nope, you're an idiot who doesn't know what he's talking
about.
One of the characteristics of the people that write things like
"Microslop" above, is that anyone that disagrees is an idiot, a
Microsoft slave, or whatever. Only THEY have the truth. All others
are stupids.

Actually, that's the attitude of Microslop engineers...I
was having no end of problems using one of their applications,
so in a desperate Google(TM) to find solutions, I came
across the "blog" of the lead engineer for the program.

In short, he blamed the users for being stupid as to
how they used the program, and then went on with a big
sob story about how freakin' difficult it was to draw
bitmaps under Windows and that's why his software was
so crappy and they had so much other stuff to do yadda
yadda yadda...standard bad engineer crybaby wailings...

URL, please.

Boy are you a glutton for punishment...I'll make some
half-hearted attempt to find it via another Google(TM)
search on the topic but like Bill Cosby, "I've seen
enough of that..."

[...]

I originally stated that they've changed the name of
the "Command Prompt" over the years...a wilted rose by
any other name, eh?

Do you call a Linux console windows an "MS-DOS command prompt"?  

I don't call it anything since I don't use Linux...

If not, why
do you insist on calling a Windows console window an "MS-DOS command prompt"?

Microslop calls it a "Command Prompt" these days, so sue
me (popular activity here) for including the "MS-DOS" which
I qualified in my first post that you did the troll-snippy
thing on...

 

[Bill Reid]

Bill Reid wrote: [...]
If you're running in release mode, VStudio already retains the console
window until you press a key, so you don't get the problem in the first
place.
Too bad the original message said he was using "Visual Studio 8
Express" so it appears you don't know how it works but that didn't
stop you from posting...
Use the Debug menu, and click "Start without debugging". That's been a
feature of VS since forever, and it was retained in VSE.
It appears you don't know how to do that, but that didn't stop you from
posting.

I don't use that IDE, but I'm skeptical that the "release
mode" works the way you describe,

BTW, "start without debugging" is not the same as compiling for "release mode".

And be as skeptical as you wish, but I'm sitting in front of a system with
VS2005 and VS2008 (plus a VS2010 beta), and they all work as described by
Mr. Heathfield.

========== hello.c
#include <stdio.h>

int main(void)
        {
        printf("Hello, world.\n");
        return 0;
        }
========== Contents of console window when run as described
Hello, world.
Press any key to continue . . .
==========

(Sorry, but you'll just have to take my word on this.)

Oh, I believe you...apparently Microslop elected to
solve the problem of people complaining about their
"console" by creating a false impression of how it
works...you know my IDE says something similar for
all "character mode" applications I write that take
or present any user input/output, because I specifically
code it into the application...

No MS-DOS here.

GOOD CATCH!!!

And who says it works that way?  

I provided a link to the console API documentation
on the Microsoft web-site, but of course it's all
technical and stuff...

Yes, it probably does work that way if you
run the program by double-clicking its icon in Windows Explorer,

GOOD CATCH!!!

though not
necessarily.  

Ever see it work differently? Provide all relevant
details, please...

And the IDE may start the program in a completely different
manner.

Of course...in all that annoying technical info that
Microsoft supplies, they are very clear that ANY application
with ITS OWN CONSOLE may start a "character mode"
application, then THAT application uses the existing
console for its input/output streams.

And, BTW, Windows (used to?) have an option for "close window on exit" for
MS-DOS applications.  Unchecking that box would leave the window open once
the program exited.

You know, I vaguely remember something like that; I
may check for it on an old system if I remember to or
actually care...

 

[Bill Reid]

More "contributions" from the brain trust that is comp.lang.c:

Zach wrote:
When I compile a C program in Dev-C++ (www.bloodshed.net) or in
Microsoft Visual Studio 8 Express it will flash a DOS window with the
results and then immediately close! How can I pause the screen? [...]
If you're running from the console, you still don't get the problem in
the first place.

Here is everything you didn't want to know or are too
technically incompetent to understand about Windows "consoles":

If you drill down you'll find that there is very clear
rule that THE CONSOLE TERMINATES WHEN THE PROGRAM THAT
LAUNCHED THE CONSOLE EXITS.

Too bad that the program he's running didn't create the console, meaning
that the above statement is irrelevant.

Yes, I know that now...too bad Microslop didn't see fit
to just pop up a "command prompt" window when you click
on a "character mode" application in Explorer, then this
whole issue would be moot...

 

[Bill Reid]

More "contributions" from the brain trust that is comp.lang.c:

Zach wrote:
When I compile a C program in Dev-C++ (www.bloodshed.net) or in
Microsoft Visual Studio 8 Express it will flash a DOS window with the
results and then immediately close! How can I pause the screen? [...]
If you're running from the console, you still don't get the problem in
the first place.

Here is everything you didn't want to know or are too
technically incompetent to understand about Windows "consoles":

If you drill down you'll find that there is very clear
rule that THE CONSOLE TERMINATES WHEN THE PROGRAM THAT
LAUNCHED THE CONSOLE EXITS.

Too bad that the program he's running didn't create the console, meaning
that the above statement is irrelevant.

The statement "if you're running from the console" means "open a console
window [typically by running cmd.exe] and run your program within it".
Since cmd.exe, which created the console, is still running, the console
window is still there.

Actually, the statement "if you're running from the console"
is imprecise use of Microsoft terms, which you are perpetuating
by attempting further obfuscation.

As I've pointed out repeatedly, Microsoft calls what you
call a "console" or "console window" the COMMAND PROMPT.
A "console" is NOT the "command prompt", rather the
"command prompt" uses a "console" for input/output. I
give you special bonus troll points for using the term
"running cmd.exe" to expertly muddy up the discussion
of something that is relatively clear (well, it IS
Microsoft, so it's not THAT clear).

And, BTW, it's not "MS-DOS" any more. The console hasn't been MS-DOS since
Win9x (95, 98, Me) days. The NT-based systems (NT, XP, 2000, Vista, Win7,
etc.) don't have MS-DOS. (They do have MS-DOS emulators, however. But the
console that you get by running cmd.exe is a true Windows application.)

Boy, what a friggin' treat...I can emulate MS-DOS in
a TRUE WINDOWS APPLICATION!!!