What makes a console app a console app?

[Everyman]

Silly question I know, but I was curious what goes on to make an app
one or the other. I tried removing the obvious differences from a
windows app, like the form inheritance, and added the arguements to
Main that a console app has, etc, and couldn't open a console for a
Writeline() call.

Since this didn't work I tried creating two completely new projects
one console and one windows. I completely replaced all of code in teh
windows .cs file with all of the code from the console app ( plus a
console.writeline() call to test it ), and still no console appears.

So where does the difference lay? Is it completly under the covers
somehow?

Is it possible to have a console output in a Windows form application?

Thanks for clearing this up.

 

[C.C. \(aka Me\)]

Each project has a property that defines what type of "assembly" will be
generated when it is compiled. If you look at the properties of your project
you should see something called "Output Type". This will be set to "Windows
Application" for a GUI app, "Console Application" for a DOS based app, or
"Class Library" if it is neither (an assembly that just has helper classes
but is not really an application by itself.)

Hope this helps!

 

[Nicholas Paldino [.NET/C# MVP]]

I believe that there is a value set in the executable itself which
indicates that an app is a console app vs a windows app, which the loader
reads, and determines whether or not to create a console and show it.

It is possible to actually get console output in a windows forms app.
What you can do is create a class that derives from TextWriter. Your
derivation would overload the Write method and then fire an event when it is
called, indicating the text that was written.

Then, in your program, you can call the static SetOut/SetError methods
on the Console class, passing your new TextWriter. In doing that, you can
attach to the events that your TextWriter exposes, and then handle it
accordingly.

Hope this helps.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

So where does the difference lay? Is it completly under the covers
somehow?

Yes and not, the loaded should know the type as he needs to create a console
window for a console app, for a win app there is more "magic" going on, like
registering windows, creating them, and starting a message pump , IIRC all
this is done by using Application.Run method.

 

[Everyman]

It is possible to actually get console output in a windows forms app.

What you can do is create a class that derives from TextWriter. Your
derivation would overload the Write method and then fire an event when it is
called, indicating the text that was written.

Then, in your program, you can call the static SetOut/SetError methods
on the Console class, passing your new TextWriter. In doing that, you can
attach to the events that your TextWriter exposes, and then handle it
accordingly.

Hope this helps.

Errr, sort of. I'm pretty new at this and the whole custom event
thing is still pretty fuzzy. I'm afraid I'm not really following the
logic in general either.

Here's what I getting from this:

public class MyEventArgs : EventArgs
{
public string output;
}

class OutputClass : Textwriter
{
MyEventArgs theEvent = new MyEventArgs();

public override void Write(String input)
{
theEvent.output = input;
// I fire an event here passing theEvent?
}
}

public class driver
{
public void main()
{
OutputClass writer = new OutputClass ();
Console.SetOut (writer);
}
}

I set the Out property to the new TextWriter. Okay so when I call
Console.Write() it fires an event. How does this event make it to the
Console? What form would the handler for this event take that would
take that EventArg and output it to the Console, especially if the
project's OutPutType property is set to WindowsApp?

It seems like all this is doing is sending a string to the new
TextWriter, and then sending it right back out again in the form of an
EventArg.

Sorry if these are dumb questions.
Thank You
Eric