I'm developing a few Windows Forms applications and I'd like to have an optional console window. I know I can do the AllocConsole() magic, however this is not the method I wish to use.
What I'd like to be able to do is run my application in a cmd.exe instance and have the console output and input work there, and all the windows will appear just like I had launched the application away from the command prompt by double clicking its icon. I also want this double clicking to work exactly the same too.
Is this at all possible? I have already tried running my program in a cmd.exe and had console output code run, however the command prompt launches the program, shows no program output, gives no input and simply goes to a new prompt line to execute a new task with the launched program still open and detached from the cmd instance.
Related
I have a C# VS2017 Console App. I'd like the CMD prompt to return immediately after executing while the App runs in the background (it's a long running process).
Currently I'm starting the App as a Process from another executable just to do this by setting Process.StartInfo properties.
Is there an opposite to Process.WaitForExit() that can be set at the start of a program?
I read somewhere using a WinForms App without the form might work, yet I tried to delete the form and sleep for 10 seconds, showing a MessageBox after (in Main). The program returned and showed the box immediately without sleeping.
I wrote the following as part of my c# console application. currently when i run this inside Visual studio or i run the .exe file manually , the command prompt will show a message, and the user need to click on any key to exist the window.
Console.Write(syncResult + " Press any key to exsit..");
Console.ReadLine();
now i want to call this console application from windows task scheduler,, so not sure if this mean that the command prompt will stay active ? i mean the .exe will keep running when a windows task call the .exe on pre-defined interval.?
Thanks
I have several tools like this running on production servers and dealt in all those cases the way people have suggested already. I have a command line argument like /q (quiet) or /u (unattended) that is checked before calling Readline:
if (!args.Any(a => a == "/q"))
Console.ReadLine();
Otherwise the Task will not complete execution and a few days later you will find lots of them still running in TaskManager. Of course when creating the task you have to remember to add that parameter in the config.
I have a a simple GUI App, which need to perform a certain function on start-up, but not on manual launch from desktop or start menu. To incorporate this function, I thought of supplying command line arguments to the application, so that depending on the command line argument, we can differentiate between launch on start up and manual launch.
My Question is that how do I make sure that whenever the user clicks the applications icon on his desktop, the required command line arguments are given to the program.
I am using C# to program my application and want to run it on windows 7
The common design pattern for Windows applications which can be launched either at startup (i.e., automatically) or manually (i.e., when a user launches the application) is to pass a command line argument when the application is launched at startup but not when a user launches it manually. Why? Because you control the mechanism by which the application is started automatically (for example, because you create a registry key in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run). So, for example, you could add a value of "c:\program files\MyCompany\MyApp.exe" /Startup And then you could check for the startup argument in your code:
bool isStartupLaunch;
foreach (string arg in args)
isStartupLaunch |= (arg.toLower() == "/startup");
By contrast, you never really can control how a user is going to launch your application. Maybe they double click on a shortcut, but maybe they double click on your actual executable, or maybe they open a command prompt and launch that way. So you don't want to rely on getting a specific command line argument when the user launches your app. Much safer to look for the automatic launch, because you control how that is done, and therefore can control the command line arguments passed in.
I have a winforms application that sometimes used from the command line.
Here is the code (simplified of course):
[STAThread]
static void Main()
{
AttachConsole(ATTACH_PARENT_PROCESS);
Console.WriteLine("Hello");
/*Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());*/
}
If that was a console application the output could be:
C:\ConsoleApplication\ConsoleApplication.exe
Hello
C:\ConsoleApplication\_
In case of windows application its actually:
C:\WindowsApplication\WindowsApplication.exe
C:\WindowsApplication\Hello
_
Can anyone tell me why do we have such difference and is it possible to make my windows application to behave like console when running from cmd?
edit:
I want my windows application to behave like console when running from cmd:
C:\WindowsApplication\WindowsApplication.exe
Hello
C:\WindowsApplication\_
solution:
As a result I'm running my application as
C:\WindowsApplication\start /wait WindowsApplication.exe
Yes. The difference is that cmd.exe is aware of the kind of executable. It knows to wait for the process to terminate when it is a console mode app. It does not wait when it is a regular Windows gui app. Trusting that it will create its own window. So it displays the command prompt again, your output gets appended to that. You'll also have trouble using Console.ReadLine() btw.
You'd have to start your program with start /wait yourapp.exe to force cmd.exe to wait. Calling AllocConsole() instead is the only universal fix. Also takes care of creating the console when your app gets started from a shortcut.
AllocConsole() is fairly disorienting. Consider writing a tiny console mode app that does nothing but Process.Start + WaitForExit to start your main program. Perhaps also munging the command line arguments. Now you get the blocking behavior back. If you rename the executable to mainapp.com (to start mainapp.exe) then the difference is hidden quite well, a trick that VS uses as well (devenv.exe vs devenv.com).
There is a flag in the exe, telling if this is a console app or gui (winform in your case) app. When you start an app, Windows will detach the console from the program if it is a console app. You can use the following approach to achieve what you want:
Compile you application as gui, name it mytool.exe
Create a doskey alias mytool=start /wait c:\path\mytool.exe $*
In this way, when you start mytool.exe in explorer or shortcut, you start a normal windows application; when you type in mytool in console, you actually start it by "start /wait", which will not detach the console regard less of the flag. (However, you do need to attach to parent console in your app if you want to output/input something from the console.
You want the Windows App to block the Console thread as long as it's running, if I understand you correctly. I have no idea why you would do that, but I can give a shot at how it might work:
Change the WinForms application to a console application, that opens a form. This way it would block the console thread while displaying a window.
a few days ago, I developed a WinForms application in C# using VC#2010 Express. After creating and saving the project, I made it a console application in the project settings, so additional to the start form, a windows command line pops up. I used the console to output debug information (simply with the Console.Write() function).
So now, my app is ready for a release. I do not want the user to see the console, for sure, but I'd like to integrate a way to show the console to interested persons. So, the best way is an argument, I think (like -console), but I dont know how to start the program as a console application only when an argument is set. I know how to handle the args[] array, for sure, but I have no idea how to show the console when there is an arg. I already tried it by simply starting the program via command line(CMD -> prog.exe), but it did not work. The program starts, but the console directly shows the current path after starting the program, as usual.
Is there any possibility for my intention?
AFAIK, there is no way to have a single binary support both console and non-console behaviour, with the choice being made on start-up. All the work-arounds I've seen use two binaries.
There's a discussion here on how Python deals with the problem (boldface mine):
The standard Python.exe that comes with Python is known as a console application (this means it has been built to interact with a Windows console, otherwise known as a DOS box or command prompt). Although you can execute your Tkinter programs using Python.exe, your program will always be associated with a Windows console. It works just fine, but has the following side effects:
If you execute Python.exe from Windows Explorer, a new empty console window is created; then the Tkinter windows are created.
If you execute a Tkinter application under Python.exe from a command prompt, the command prompt doesn't return until the Tkinter application has finished. This will be a surprise for many users, who expect that executing a GUI program returns the command prompt immediately.
To get around this problem, Python comes with a special GUI version called Pythonw.exe. This is almost identical to the standard Python.exe, except it's not a console program, so doesn't suffer the problems described previously.
You could get the command line arguments for the Winform in the forms load event and then if the argument is for the console, open the console.
private void Form1_Load(object sender, EventArgs e)
{
string[] args = Environment.GetCommandLineArgs();
foreach(string arg in args)
{
if(arg == "consoleargument")
{
// Run console
}
}
}
You can link to kernel32.dll and use the function AttachConsole.
Here's an example: http://www.csharp411.com/console-output-from-winforms-application/