Console application

  • Thread starter Thread starter James
  • Start date Start date
J

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
 
James said:
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.
Click to expand...

Change your app from a Console Application to a Windows Application to
prevent Windows from creating a console for it.
 
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.
 
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.
Click to expand...

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
 
If you don't want the visual aspect of this Windows app, then you should be
making a Windows service project.

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
 
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.
Click to expand...

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.
Click to expand...

I'll agree there.
A Windows Service is for just this kind of thing.
Click to expand...

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
 
Scott said:
If you don't want the visual aspect of this Windows app, then you should be
making a Windows service project.
Click to expand...

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.
 
* 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.
Click to expand...

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
Click to expand...

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.
 
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.
Click to expand...

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
 
* 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.
Click to expand...

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.
 
Back
Top