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/
Related
This question already has answers here:
Output to command-line if started from command line
(3 answers)
Closed 2 years ago.
I have a windows forms application with a working GUI. However I want the application to be able to be started and used in a command-line interface aswell as a regular GUI application. When the application is started in an CLI the GUI shall not be used an instead relevant information will be written to the CLI-application. What I need to do this is a way to detect if the application (its exe file) is started in a CLI-application such as the regular windows CMD or started in a normal fashion such as clicking the exe file in the file explorer or using a desktop shortcut.
Preferably the detection should be done in the main method of the application such as
static class Program
{
[STAThread]
static void Main()
{
//if(application not started in a CLI-application)
Application.Run(new DriverToolApplicationContext());
//else
//Console.writeLine("Application started in CLI-application");
}
}
How is this detection best implemented? I preferably do not want to put any arguments in the main method.
I think you'll struggle without arguments tbh; most apps I can think of that have this dual mode operation bundle as two exes, a gui one and a command line one (and one maybe uses the other)
It really is the simplest way to just have rules:
if the application is started with no arguments, print(and/or messagebox.show) the command line arguments and quit
if the app is started with eg /gui argument (baked into the windows shortcut) it runs as gui
if the app is started with other arguments for command line operation, proceed as per those arguments
You can vary these of course, maybe you would have:
if the application is started with no arguments, run as gui
if the app is started with eg /? argument print the command line arguments and quit
if the app is started with other arguments for command line operation, proceed as per those arguments
I make this recommendation chiefly because, to be really useful as a command line app an app probably needs to take arguments from the command line, so you can use their presence or absence to infer where the app was started from. It's not perfect, of course - a shortcut can "start from windows" but pass arguments that will make i the app think it was command line, but where I'm getting to is that generally that doesn't matter because this question is not so much about "where it was started from?" as "does the app have enough info to do its work or must it ask the user for info?"
To do this without command line parameters you would need to be able to find what process launches your one. This question shows how to find the parent process id Finding parent process ID on Windows
However, if you launch a program from command prompt it's parent process id is not the one that the command prompt has. You might have to do something that reads event log and after all that realise that what you need will require admin rights. The above suggestion to use command arguments is probably a better solution but I'd be curious to see if it can be done without them.
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'm writing a little utility which has a WPF based interface. I also want to be able to automate the same tasks performed by the utility by executing a program with command line parameters. Is it a bad idea to combine both of these tasks into one program? I have the actual logic and functionality that my tool performs in a separate shared library. So I wouldn't be duplicating a whole lot of code if they were separate.
I was thinking of doing something like this in my App.cs file
private void Application_Startup(object sender, StartupEventArgs e)
{
if (e.Args.Length > 1)
{
//Go do automated tasks
}
else
{
//open GUI
Window window = new Window();
this.MainWindow = window;
window.Show();
}
}
You are not actually creating a console so this is not a console mode app.
A GUI program accepting arguments is entirely normal. The boilerplate example is a file association. Like double-clicking a .sln file in Windows Explorer starts Visual Studio which then loads the solution. Double-clicking a bitmap starts MS-Paint. Etcetera. The path of the clicked file is passed to the program through a command line argument, just as if you typed it in the command interpreter.
Whether or not you create a window is entirely up to you. Don't forget the need to report problems.
In this case I would create a functional class library that is invoked from different Host projects. MyApp.WPF references MyLib as a dll...MyApp.Console references MyLib as a dll.
edit I see that you already have the class library with the functionality segregated. What is the real benefit of keeping it in the same application then?
You can definitely do this to run automated tasks or set options from the command line, but keep in mind that a WPF application has no console window, so you won't be able to use Console.WriteLine() or anything like that. If you don't need console output, maybe that isn't a big deal.
There may be some awful win32 hack to attach a console window to a WPF application, but I wouldn't recommend that. If you need a real console, building both a WPF and console front end for your library may be the way to go.
I would also recommend Options.cs to do command line argument processing in C#.
EDIT: I may be wrong about all this, see the comments.
ALSO: Related information about windows application vs. console application: Difference between Windows and Console application
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.
I am trying to writing a console application. It has its original console, let's name it console A. And I want this application to do the following things via C#:
Open another console B in another thread, then get input from A and output it to B;
type a command in A, such as dir, and show the output in B;
while doing the above things (still not done yet. X_X ), I find myself lack a through understanding of what a console window is, and how it is assigned to a console application, especially the very first console when my console application starts to run. Could some one shed some light on me?
Is console window physically a memory area in the video memory? Or something else?
Could different threads within the same process have different console of its own for its own I/O?
Many thanks.
Now I am using one console application to start another console application in a new process. Thus I can have 2 consoles output at the same time.
My understanding now is that, for Windows OS, a console is a special window, and it's a system resource that OS assigned to the application without-a-UI as a necessary user interface. Windows OS handles the wiring between the system-prepared console window with our UI-less application.
In Windows terms, a Console is a textual GUI window that you see when you run "cmd.exe". It allows you to write text to, and read text from, a window without the window having any other UI chrome such as toolbars, menus, tabs, etc,..
To get started you'll want to load Visual Studio, create a new project and choose "Console Application". Change the boilerplate code that Visual Studio produces to:
using System;
using System.Text;
namespace MyConsoleApp
{
class Program
{
static void Main(string[] args)
{
Console.Write("Hello, world!");
Console.ReadKey();
}
}
}
When you run your application, a console window will open with the text "Hello, world!" and it'll stay open until you press a key. That is a console application.
Is console window physically a memory area in the video memory? Or something else?
It's not physically a memory area in video memory, it's "something else". The Wikipedia Win32 console page gives a fairly robust descrption of the ins and outs.
A console application has only one window. It does not have window management functions in order to spawn child "consoles".
You can start additional console applications, but these are separate entities.
No. It's a windows GUI subsystem. In WinAPI there are functions to work with console: http://msdn.microsoft.com/en-us/library/ms682073%28VS.85%29.aspx
A (OS) console is a process (containg one or more threads of executions, all of them sharing the same memory space), and this process has:
standard input (a stream of input bytes), what you key in
standard output (a stream of output bytes), what the program prints
standard error (a stream of output bytes), what the program prints when it's complaining about something
So if you want to create another console (from .Net) and link the input/outputs I understand you have to create a process (executing "cmd.exe" by example).
I don't know the API of .Net for process manipulation but if it's like Java you can hook up stdin, out and err so you can play with your created process from the original one.
A windows application can have one console, or no console, it can't have more than one. See the documentation for AllocConsole.
The console is basically an emulation of the 'pre-Windows' days when there would literally be a 'control console' i.e. a keyboard and screen attached to a mainframe computer.
To do what you want you could spawn another process with its own console and communicate between the two, or make a GUI application which looks like a console window.