Printable View
Hi guys!
First of all: I am totally new to the laguage C# - just learning the basics right now. I have some experience with C and C++ though. I just typed a simple program and compiled it, but it's hard to tell whether it's working or not, as the program closes immediately after launch. Is there some kind of pause function that can be used to delay shutdown of the program until the user presses a key? (like the one in C called system("pause"))
Ask for input. That's usually the best way to go about it. Especially in C# where you have direct control over keypresses and can simulate the getch/kbhit dealie that everyone wants in C++.
thanks a lot!! :-) now I'm on my way to mastering what appears to be the programming language I've dreamed of..hehe.
C# is a nice language, but that's mostly due to the .NET framework. I find .NET development to be very pleasant, if mindless a lot of the time because everything is so darn easy to do. ;)
haha yeah you are right - I guess that's what makes it seem very nice for noobs like me. Haha!
You can interop it with msvcrt.dll, I believe. Ah, here's my old reply to the question:
You have to pinvoke this C function into your C# application. Luckily, this process is very easy. There are a few steps:
1) Insert System.Runtime.InteropServices to your using clauses.
2) Insert this line in your class (usually in the first few lines)
[DllImport("msvcrt.dll")]
static extern bool system(string str);
3) In that same class, simply write this:
system("pause");
Hope that helps! It's not the best solution in C# to go about the problem, but hey, it's a solution.
It sure is an ugly solution dxfoo.
Like prelude said, ask for input.
Simple and works fine, no need to work with interop or anything.Code:Console.ReadLine();
If there is anything you should do with C# is use the classes that are already written. You'll be sure that there are no bugs in it. The only time one can write his own class to replace a class already available in the framework could be for learning purpose.
I'm just proving you can do it if you really need to, but yeah, Console.ReadLine() is the way to go.
>I'm just proving you can do it if you really need to
As if that were necessary.
Okay, I'm really beginning to wonder if it's me that's always negative or if it is really you guys. The function system("pause"); actually has code that the user isn't able to do with Console.ReadLine() Try writing several letters with system("pause"). It will find one pressed and continue as expected. It will do the opposite with Console.ReadLine(); which may not even be acceptable to the developer. Not to mention, 'press any key to continue' with Console.ReadLine() and you are pressing 500 keys and it will display ALL 500 of them, and the program won't continue until you press enter. It's more like "press enter to continue" and you can type a million things before you do so before pressing 'enter' which is absolutely unprofessional, and I can tell that Prelude falls in this area. They do slightly different things, and it is up to the developer to decide on what he needs to do. I presented a slightly different solution that can give the developer some differnet options so he can choose what is best for his project. If at all, this solution would be more professional towards the end user. This was an absolute waste of time to clear up Prelude's stupid remarks. Options are good. Learn what they are and move on.
>I'm really beginning to wonder if it's me that's always negative or if it is really you guys.
It's really us. We tend not to take kindly to bad advice, and suggesting overly complicated and inferior solutions is akin to bad advice.
Your entire argument is nothing more than hot air in light of the solution that I originally suggested. Since it wasn't as obvious to you as it was to me, I'll clarify the complete solution that simulates system("pause") exactly, with code:Quote:
The function system("pause"); actually has code that the user isn't able to do with Console.ReadLine() Try writing several letters with system("pause"). It just won't happen. It will with Console.ReadLine(); which may not even be acceptable to the developer. Not to mention, 'press any key to continue' and you are pressing 500 keys and it won't do anything. It's more like "press enter to continue" and you can type a million things before you do so which is absolutely unprofessional. They do slightly different things, and it is up to the developer to decide on what he needs to do. I presented a slightly different solution that can give the developer some differnet options so he can choose what is best for his project.
QEDCode:public static void Pause()
{
Console.Write("Press any key to continue . . . ");
Console.ReadKey(true);
}
Despite the absence of need, I just thought I'd chime in.Define "end user" and guarantee to me that you wouldn't have to port your implicit PInvoke. This solution breaks any hope of being CLS compliant. Please help me understand why you'd even suggest such a poor solution when there are obvious superior ones.Quote:
Originally Posted by dxfoo
Interesting idea on the Console.ReadKey() method, but all these insults are very pointless, though. And CLS compliant? Who gives a rip if system("") is meant to target Windows and the system of which various system-specific commands reside in. Pausing a "console" isn't needed outside of the CLS, but I stated that system() can still be called if wanted. Every professional program goes outside of the CLS to get tasks done such as Win32 and their own specific dll's. It makes me assume that you're new to development and had no reason to go outside of the sandbox to get tasks done. Please, argue about something that's more interesting than what's the best way of calling "pause" on a console window. This is just scaring me.
Yeah, go to my threads and answer at least one of them.Quote:
Please, argue about something that's more interesting than what's the best way of calling "pause" on a console window. I can't believe you guys have nothing better to do.
I looked and found 90% of them very basic questions and not even worth replying to. You might want to try harder and then the sarcasm. But quite honestly, I'm sick of message boards finally. I'm working with great professionals here at work, and I come home every other day to check up on the latest posts at various message boards. None of them are worth my time! 90% of them are so misinformed or basic that I wonder what the hell just happened from work and to these boards. I just figure these boards are common to the average person who has nothing better to do, so perhaps it's just time to leave as most folks I know who did the same thing. At work we don't talk about what the best way is to pause windows :) I know, it's shocking! And I don't miss it.
You are a free man. I can't remember anyone forcing you to use message boards.
Some of us find them usefull others like you obviously don't.
I like my coffee with milk and sugar, others don't.
Which does not imply I am superior just because I drink it that way.
I'm sorry, maybe that really reads, "Every professional program that you've worked on"? I have no reason to go outside of the 'sandbox', as you put it, for two reasons: the CLR standard defines enough interesting functionality to not require it often, and it's in the design specification. Believe it or not, the overwhelming majority of my company's code is CLS compliant. You may assume whatever makes you feel good about yourself; it doesn't change the reality of the situation.Quote:
Originally Posted by dxfoo
Congratulations. You and your co-workers have advanced beyond that point; hopefully more than one of them takes the sensible way out instead of PInvoking needlessly.Quote:
Originally Posted by dxfoo
>Who gives a rip if system("") is meant to target Windows and the system of
>which various system-specific commands reside in.
Just because you don't care doesn't mean that others don't. It's assumptions like this that produce crappy code.
>Every professional program goes outside of the CLS to get tasks done such as Win32 and their own specific dll's.
Really. Well, you're wrong because I can name at least one professional program (that I worked on recently) which uses CLS exclusively.
>It makes me assume that you're new to development and had no reason to go outside of the sandbox to get tasks done.
Pot. Kettle. Black.
>Please, argue about something that's more interesting than what's the best way of calling "pause" on a console window.
It's not the details, it's the principle. If you suggested an exceptionally poor way of loading employee records from a database via ODBC in a professional payroll system, the discussion would have followed a similar path.
>I looked and found 90% of them very basic questions and not even worth replying to.
>None of them are worth my time!
I can't respond to this in a way that wouldn't break forum rules. You're welcome to leave and never return if this is how you see our community.
>90% of them are so misinformed or basic
Look at your own posts before complaining about the posts of others, please.
>At work we don't talk about what the best way is to pause windows
If you can imagine, I talk about slightly more important things at work as well. Work related topics. Probably topics well beyond your current experience level. Why? Because the people I work with already know the basics and don't need to debate it.
If dxfoo is not satisfied with these simple questions, why not asking him some harder questions?
dxfoo, can you please tell me your knowledge area? You are only exprienced in C# or you are experienced in x86 assembly too?
If you are bored I will ask some hard question to put you in trouble with them.
If there is no alternative in C#,we can use System("pause") provided in msvcrt.dll,maybe it is not the best or the easiest way to do that,but we can learn from it,as we will know if we want to use those system calls in a C/C++ program,we can import msvcrt.dll :)
I am also a beginner at C#,and I reached here with google when I searched answers to my question,I think dxfoo is helpful to us,isnt he?
Quote:
Originally Posted by dxfoo
myusername, kindly do not resurrect old threads unless you have a very good reason.
*thread closed*