Alternative to Console.ReadLine() to keep the Console visible

Question

Isn't there a better looking statement (or way) to keep the console from disappearing than the hackish Console.ReadLine() call. Something that's more expressive of the purpose of, more orthogonal to, keeping the Console visible ?

Why does the console close down when the program has not made a call to do so ? Suppose the only statement in my program is Console.WriteLine("Hello world"); Now what would you expect a sane execution of this application to look like ?? — explorer, Sep 27 '10 at 23:43
The all .net applications start with main methods begining brace ({) and ends when the cursor reaches the closing brace (}). so you had to stop cursor Bedir'e reaching the closing brace. To achive that the simpliest way that offered is waiting for a KEY from client. Another way, after you sucessfully build your solutuion you run by command via command prompt; so the command prompt won't close it self. — bahadir arslan, Sep 28 '10 at 05:18
Bedir'e means before. I am sorry, sometimes this spelling controls get crazy. — bahadir arslan, Sep 28 '10 at 05:43

score 9 · Accepted Answer · answered Sep 27 '10 at 18:07

9

If you are still developing application you can run via Ctrl + F5 (Without debugging) otherwise you can use Console.ReadKey() (same but there is no more option)

answered Sep 27 '10 at 18:07

bahadir arslan

4,535
7
44
82

jsmith · Answer 2 · 2010-09-27T18:43:47.823

5

You can do:

Console.ReadKey();

Console.ReadLine() is not really hackish, your pausing the screen to wait for input. The input can either be a single key, or a string.

Update

One nice thing about the ReadKey() method is that it "waits, that is, blocks on the thread issuing the ReadKey method, until a character or function key is pressed." MSDN

This is different than ReadLine which takes in a string. Arguably, cleaner.

edited Sep 27 '10 at 18:43

answered Sep 27 '10 at 18:05

jsmith

7,198
6
42
59

1

I am almost certain the OP will be exactly as happy with this solution as the workaround he already mentioned. – Kirk Woll Sep 27 '10 at 18:07
@jsmith, I don't understand why you think ReadKey() provides an advantage over ReadLine() for the purposes of this question. What do you mean, "Which for console you're always waiting for an input."? – Kirk Woll Sep 27 '10 at 18:11
@jsmith, um...so you think the problem the OP had was that he didn't like the word "Line"? (otherwise the "syntax" is identical) – Kirk Woll Sep 27 '10 at 18:19
@Kirk Woll your being awfully opinionated about this one when there is just cause for my answer. From the OP "Isn't there a better looking statement", "something that's more expressive of". Those two quotes make me think he is looking for something that describes the act more. When you are pausing the screen, you are not looking to read a line. But to read a key. Typically the space or enter key. – jsmith Sep 27 '10 at 18:22
@jsmith, you should probably consider calming down. Consider: you just claimed that there was no advantage to your solution -- and now you are saying that it is "better looking" and "more expressive". – Kirk Woll Sep 27 '10 at 18:30
@Kirk Woll you seem to be trolling a bit, saying things like "calm down" based on text is very subjective and argumentative. I am quite calm. I don't quite understand how you know so well what the OP is asking for. I have updated my answer to try and satisfy you. – jsmith Sep 27 '10 at 18:39
Console.ReadKey() is not a bad suggestion. Its certainly cleaner but its still a statement that does not express the fact that its there just to keep the console from shutting down. – explorer Sep 28 '10 at 05:27

score 2 · Answer 3 · answered Sep 27 '10 at 18:05

It depends on the context. If you're talking about running a command line, debugging through your code, and then being able to view the results on the console you have two options:

If you run with the debugger attached (f5), you must use Console.ReadLine
If you run without the debugger attached (ctrl + f5), it will stay open ... but then you obviously can't debug through.

I'm not sure why that's the default behavior, but there it is :-)

score 0 · Answer 4 · answered Jan 01 '13 at 10:52

I usually use one of these:

Console.ReadKey(true); //You might want to put this in an infinite loop
new AutoResetEvent(false).WaitOne();

In VS You can also run (Ctrl + F5) the program (in distinction to running in debug) and it will add a system pause after it finishes executing.

I'd say that WaitOne, and just running (& not debugging) the program are your non-hackish options.

If you do want to debug, perhaps set a breakpoint at the last }.

score 0 · Answer 5 · answered Aug 17 '16 at 19:32

Depends on what I am doing. If I am doing multi-threaded work and want my Console application to remain alive until all other work is done, I usually do something like this. (Similar to MasterMastic)

using System;
using System.Threading;

namespace Test_Console
{
    class Program
    {
        static EventWaitHandle EWHandle;

        static void Main(string[] args)
        {
            EWHandle = new EventWaitHandle(false, EventResetMode.AutoReset);
            Thread WorkThread = new Thread(new ThreadStart(DoStuff));
            EWHandle.WaitOne();
        }

        static void DoStuff()
        {
            Console.WriteLine("Do what you want here");

            EWHandle.Set();
        }
    }
}

Of course, there's always just using the regular breakpoints and the other debugging tools if that's what you're going for.

Alternative to Console.ReadLine() to keep the Console visible

5 Answers5

Linked