Console application

[James]

I have a simple console application. When it starts it opens a dos box until
termination.
Is it possible and how to eliminate the dos box, leaving the rest
functionality.
Regards
James

 

[Scott Seligman]

I have a simple console application. When it starts it opens a dos box
until termination. Is it possible and how to eliminate the dos box,
leaving the rest functionality.

Change your app from a Console Application to a Windows Application to
prevent Windows from creating a console for it.

 

[sloan]

I use this to make the window 90% wide and high.

Console.WindowWidth = (Console.LargestWindowWidth * 9 / 10);

Console.WindowHeight = (Console.LargestWindowHeight * 9 / 10);


My guess is that there are some other properties (.Visible? I don't know
offhand) which you can use.
Or at least use the above to make it really really small.

 

[sloan]

No .Visible property.

http://msdn.microsoft.com/en-us/library/system.console_properties.aspx

So either the (previously mentioned" winform idea. Or make the console as
small as possible.

 

[Peter Duniho]

I have a simple console application. When it starts it opens a dos box
until
termination.
Is it possible and how to eliminate the dos box, leaving the rest
functionality.

Does it really need to be a console application, and if so, how are you
starting it?

Normally, the window would go away on its own. But a shortcut to the
process can be set to leave the window open, and if I recall correctly
there are other ways to control that as well.

If you can avoid making the program a console application, that's
obviously the best solution. But otherwise, you should look into whatever
is causing the window to stay in the first place.

Pete

 

[Scott M.]

If you don't want the visual aspect of this Windows app, then you should be
making a Windows service project.

Scott M.

 

[Scott M.]

By definition a Console app will show the console, albeit for the shortest
amount of time possible unless something causes it to stay open, like a
Console.ReadLine() method call. Barring that, it is completely normal to
briefly see the console when the application is started.

If no UI is desired, then this is the wrong project choice. A Windows
Service is for just this kind of thing.

-Scott

 

[Peter Duniho]

By definition a Console app will show the console, albeit for the
shortest
amount of time possible unless something causes it to stay open, like a
Console.ReadLine() method call. Barring that, it is completely normal to
briefly see the console when the application is started.

Ah, exactly right. I mis-read the original question and thought the OP
was seeing (and asking about) the window remaining after the process had
actually exited.

But I see now I was mistaken, and the question is actually about the
presence of the window even while the process is running.

If no UI is desired, then this is the wrong project choice.

I'll agree there.

A Windows Service is for just this kind of thing.

I'll disagree there. A Windows Service is not for any random UI-free
program. It's for a specific kind of UI-free program.

If the OP simply doesn't want a window, then he should just not make it a
console program. By marking the program as a console application, he's
specifically asking Windows to create the window. If he'd just stop doing
that (by marking the process as a regular Windows application instead of
console application), then Windows wouldn't create the window and he'd be
fine.

Pete

 

[Harlan Messinger]

If you don't want the visual aspect of this Windows app, then you should be
making a Windows service project.

I don't think so--it sounds like it's meant to be an
executable-on-demand application. In other words, a Windows Forms
project with the default Form1.cs deleted, and the call

Application.Run(new Form1());

in the Main() routine replaced by the application code.

 

[Jesse Houwing]

* Peter Duniho wrote, On 10-9-2009 20:10:

[...] In other words, a Windows Forms project with the default
Form1.cs deleted, and the call

Application.Run(new Form1());

in the Main() routine replaced by the application code.

Actually, he should delete the project's reference to the
System.Windows.Forms assembly, and remove any code that fails to compile
once that's done. If there's no UI, there's no reason to keep any of the
System.Windows.Forms stuff around.

Oddly enough, we _just_ answered basically this same question over the
past couple of days (see "Creating a Project no form").

Pete

Even easier than creating a new project is to go to the project
properties and set the Output type to Windows Application (it's on the
Application tab). If you already had a Console App it will automagically
no longer show the console without having to change a single line of code.

 

[Peter Duniho]

Even easier than creating a new project is to go to the project
properties and set the Output type to Windows Application (it's on the
Application tab). If you already had a Console App it will automagically
no longer show the console without having to change a single line of
code.

Yes, if the project already exists and is a console application, it's
easier to just fix the project type.

For a new project, it seems to me that the relative difficulty is about
the same between both methods. The project setting is in just one place
but, at least on my computer, that property page takes longer to load than
simply selecting and deleting an assembly reference and related pieces
(i.e., it's a couple of clicks and keypresses to get rid of the assembly
and the Form1 class, and then just a quick visit to the Program.cs file,
which would have to happen during the course of implementing a console
application in the first place.

In other words, there's more UI interaction starting with a Forms project,
but the interaction can happen more quickly.

YMMV.

Pete

 

[Jesse Houwing]

* Peter Duniho wrote, On 10-9-2009 21:35:

Yes, if the project already exists and is a console application, it's
easier to just fix the project type.

For a new project, it seems to me that the relative difficulty is about
the same between both methods. The project setting is in just one place
but, at least on my computer, that property page takes longer to load
than simply selecting and deleting an assembly reference and related
pieces (i.e., it's a couple of clicks and keypresses to get rid of the
assembly and the Form1 class, and then just a quick visit to the
Program.cs file, which would have to happen during the course of
implementing a console application in the first place.

In other words, there's more UI interaction starting with a Forms
project, but the interaction can happen more quickly.

YMMV.

Hehe... I agree... with you when I'm at work... Customer has me working
on an old Sempron with a 4800rpm harddisk and a way to small amount of
memory...

But on my Core i7 with an Intel SSD it all happens in the time I'm able
to click properies. I love this new system. I might even bring it along
to work to show how much more productive I would be with it.