3

Possible Duplicate:
Can one executable be both a console and GUI app?

I'm writing an program in C# which by default runs as a standard "Windows Application" (Project Properties -> Output type).

Its normal behaviour is that it gets run from a shortcut or whatever and displays a GUI.

However with certain command line arguments, it will run as a console application, display no GUI and return an exit code to the calling shell.

I've hit a snag in that if I compile it as a "Windows Application", when it runs it forks and the parent thread returns to the calling process immediately, with the program still running in an independent child thread. This means that it can't return an exit code to the calling process when it terminates because that has already happened when the program started up and forked. As far as the calling process knows, the application always completes immediately and returns zero.

For a straight console program, the answer is simple - compile it as a "Console Application". In that case, the application doesn't fork at startup and the calling process waits until the program finishes and returns an exit code. Unfortunately, going down this route, Windows always displays a command window (console, whatever you call it... big black thing!), which nasty if the program is running in its GUI mode. I suppose I could make a an API call to hide that window, but it would still flash up momentarily.

So, is there a way to stop a "Windows Application" from forking when it starts up? Or alternatively is there a way to control whether a "Console Application" displays a console window? Ideally this would be done C# code, giving me the ability to choose what happens based on the command line arguments.

I've seen posts from people asking similar questions, but not found a proper answer (mostly, respondents don't understand the forking business).

I've just completed the Cocoa (Mac) version of this application (which does exactly what I'm trying to achieve here). It would be a shame if the Windows version couldn't do it. It must be possible! :-)

Any ideas would be appreciated.

Community
  • 1
  • 1
Matt Ralston
  • 86
  • 3
  • 1
    Does your application have an explicit main method, or is it running a form on startup? If the former, can you post the main method here? – Chris Shain Apr 23 '12 at 16:32
  • Thanks, sixlettervariables, I didn't spot that one. I'm going to have a read of Raymond Chen's blog now. In the meantime, Chris, http://pastebin.com/FvEA8LgA – Matt Ralston Apr 23 '12 at 16:43
  • I think I'm going to go down the two projects (one GUI, one TUI) in one solution option. If it's what MS did for Visual Studio then it sounds like the way to go. I've not tried it before, but hopefully I can share some of the code between the two projects. – Matt Ralston Apr 23 '12 at 17:08
  • We use the two projects approach (and have them share a common library of functionality). – user7116 Apr 23 '12 at 17:14
  • To clarify one point: the application is not "forking". The parent process can choose to wait until it exits and retrieve the exit code, and you do this in exactly the same way for GUI and console applications. However, cmd.exe does not choose to wait for GUI applications run interactively. Note also that cmd.exe *will* wait for a GUI application to exit when the application is run from a batch script. – Harry Johnston Apr 23 '12 at 22:01

0 Answers0