Is my application running from a console?

[Eric Falsken]

Is there a way to tell if my application is running from a command line
(console) or if it is running in a windowed environment (double-clicked)?

I want to send errors to a popup if it's windowed, or to the console if
it's command-line.

 

[David Browne]

Is there a way to tell if my application is running from a command line
(console) or if it is running in a windowed environment (double-clicked)?

I want to send errors to a popup if it's windowed, or to the console if
it's command-line.

If you don't know, you shoudn't. A .dll shoudn't access either of these
resources. Both the UI and the Console belong to the application, and the
application should be in charge of what to display. For instance, what if
it's a windows application, but it's running in a hidden desktop, or as a
service, or minimized?

For errors just throw an Exception. It's up to the calling application to
decide how to display them.
For informational messages, just pipe them to System.Diagnostics.Trace. The
calling application can attach a TraceListener to get these messages and do
whatever with them.

David

 

[Eric Falsken]

If you don't know, you shoudn't. A .dll shoudn't access either of
these resources. Both the UI and the Console belong to the
application, and the application should be in charge of what to
display. For instance, what if it's a windows application, but it's
running in a hidden desktop, or as a service, or minimized?

It's not a DLL. It's an executable. But now I'm noticing that
Console.WriteLine statements are ignored (only sent to VS Debugger
Console window) if the app is compiled as a Windows Application.

I'm trying to create a Windows Application that can also be batch run
from the command prompt. But I need to know where to send my error
messages. And now, I have the added task of getting my Console output to
show up.

 

[Eric Falsken]

It's not a DLL. It's an executable. But now I'm noticing that
Console.WriteLine statements are ignored (only sent to VS Debugger
Console window) if the app is compiled as a Windows Application.

I'm trying to create a Windows Application that can also be batch run
from the command prompt. But I need to know where to send my error
messages. And now, I have the added task of getting my Console output
to show up.

If I compile as a Console Application, there's an ugly black window that
won't go away. But it can still popup MessageBox messages, and display
windows forms.

If I compile as a Windows Application, Console Output is not shown when
run from the command line, but the black window is gone.

What's going on here, and how can I make it work? What I'd like to do is
to run my application executable, and depending on what command line
parameters are sent to it, to either just output some text to the
console, or to enter the full "interactive" mode. I'd rather not make
them 2 seperate applications.

 

[mato]

If I compile as a Console Application, there's an ugly black window that
won't go away. But it can still popup MessageBox messages, and display
windows forms.

If I compile as a Windows Application, Console Output is not shown when
run from the command line, but the black window is gone.

What's going on here, and how can I make it work? What I'd like to do is
to run my application executable, and depending on what command line
parameters are sent to it, to either just output some text to the
console, or to enter the full "interactive" mode. I'd rather not make
them 2 seperate applications.

you can compile your application as a Console app, and free console window
with this function.

[ System.Runtime.InteropServices.DllImport( "kernel32" ) ]
private static extern bool FreeConsole();

so in your code it will look like this:

[ System.STAThread ]
static void Main( string[] args )
{
if( do not want to use console )
{
//free console if you do not want to show it
bool success = FreeConsole();

//some win forms code
}
else
{
//some console using code
}
}

hope this helps.
mato

 

[Nick Malik]

Encapsulate the variation.

Everywhere in your app that you are calling Console.Writeline, change it to
AppConsole.Writeline...
write an AppConsole class with a static Writeline method

At this point, you can be Object Oriented or Procedural...

OO method:
Create an interface class that has a SendOutput method defined
Create two classes that inherit from the interface. One will send to the
console, the other to a windows form
Create a factory object that will create one of these two different objects,
based on how the app is started.
At startup, call the factory object. Get the child object. Assign it to the
AppConsole class to use.

Procedural:
In the AppConsole.Writeline method, check the value of a static variable to
decide if the output should go to the console or a windows form.
At startup, set the static variable.


Good luck,
--- Nick

 

[Eric Falsken]

Right, I'm already doing that. But there's no way to tell if the application was spawned by
a Command Prompt, or if the process was launched using Windows or a Windows API or from a
windowed process. I need to figure out IF the application is running in a command line.

 

[Nick Malik]

right, but if your app is running from a console, then the MAIN() routine
was invoked. If it is running from a DLL, the MAIN() routine would not be
invoked. So have the main routine create an object for writing to console
an pass that in to the constructor. If another app starts your app via a
direct dll call, have the other app send in an object (which you can provide
the code, or it can provide the code, adhering to an interface).

If started from ProcessStart, that's the same as starting from the console.

--- Nick

 

[Eric Falsken]

right, but if your app is running from a console, then the MAIN()
routine was invoked. If it is running from a DLL, the MAIN() routine
would not be invoked. So have the main routine create an object for
writing to console an pass that in to the constructor. If another app
starts your app via a direct dll call, have the other app send in an
object (which you can provide the code, or it can provide the code,
adhering to an interface).

If started from ProcessStart, that's the same as starting from the
console.

I want to know if the user double-clicked an icon, or if they typed it into
a command prompt. Main gets executed either way. But there has to be a way
to determine in which context the application should behave. It's an EXE
executable. Nobody is making direct calls.

 

[Nick Malik]

now I see why I wasn't understanding you. Normally, there is a huge
difference between a windows app and a console app (especially in earlier
days of Windows programming). You just didn't see many apps that tried to
be both. In effect, it's either a windows app, or it isn't. If it is
started at the command line, it is still a windows app.

Look, what I'd suggest is that you put all the logic in a DLL. Then create
a small windows GUI to call the dll. Info goes to the u/i.
Create a seperate console app to call the dll, that can be started at the
command line. Info goes to the console app.

If the user starts the windows app, from the command line, they want the
windows gui.
If the user double-clicks the console app, they still want console output.

--- Nick