Having a Windows App act like a Console app

[lmortenson]

Hi, I'm working on a graphical application which I'd like to potentially use in an automated command line process. So, the if the user wanted to batch a whole bunch of operations, they could pass some arguments to the executable through the command line and it would act like a console app, not displaying any forms and just writing to standard output. It wouldn't even have to be interactive. I played around with it a bit and reading arguments passed in is fairly trivial, but even when I tell it not to initialize components, a blank form always pops up. Any suggestions on how I could do this?

 

-Lars

[PlausiblyDamp]

Rather than having the start up object being a form make it a sub main, then if no parameters are passed launch the default form. If they do pass any parameters then run the relevant code and exit without displaying a form.

[mskeel]

I am trying to do a similiar thing but I am having a problem with my command line section. I can get my program to show the gui when there are no arguments written and to run command line when there are arguments, but I can't seem to be able to write comments to the command prompt when my program runs as a command line app.

 

I am using traditional console.writeline commands to write these. They work fine on a strait up console app...

 

What could be going on? Could it have something to do with the fact that this app was declared as a gui app?

 

Thanks..

[pelikan]

what you're trying doesn't sound plausible - the compiler creates either a

windows executable, or a console app - you can't have it both ways - try

factoring out the common code into classes and create two executables.

[mskeel]

what you're trying doesn't sound plausible - the compiler creates either a

windows executable, or a console app - you can't have it both ways - try

factoring out the common code into classes and create two executables.

 

That is just rediculous. Creating two executable doesn't make sense and is rather silly. There are a lot of different work arounds for this but no real answers. One executable, two ways to use it.

 

There is no reason why it should matter what type of executable you create. The only difference between the two, from a compiler perspective is the linking (you might want to link into System.forms.dll for example if you want to make a dialog). Another difference is that in a form you are going to use an event loop in your main function. There is no plausible reason why creating a form would prevent you from writing to the command prompt.

 

Visual studio does make it somewhat difficult to do advanced things by hiding a lot of low level details, but there must be a reason why this doesn't work. And there must be a way to make it work. Perhaps stdout is made null by the execution of a dialog to prevent debugging console.writelines from showing up inadvertantly? Just a theory. If that's the case, how would I prevent that from happening?

 

Maybe the best solution would be to use a console app solution and just put an event loop in the main function if the user doens't specify arguements. That is one theory I think I am going to try.

 

It just doesn't work is not an answer. It works in one type of executable but not in the other. What is the difference and why is there one?

[mskeel]

It works

 

As it turns out, declaring your startup project as a console app will allow you to both write out to the command prompt using console.writeline, and throw up forms if you so desire. All you have to do is override the main function in the startup module of the console app.

 

   Public Sub Main(ByVal arguments() As String)
       For Each arg As String In arguments
           Console.WriteLine(arg)
       Next

       If arguments.Length > 1 Then
           Console.WriteLine(arguments.Length.ToString)

       Else 'Run the GUI
           Dim TestForm As MainForm = New MainForm  'the name of my form class
           TestForm.ShowDialog()
       End If
   End Sub

 

The big question here is why doesn't this work when declaring a win32 form app? The most probable answer is that the stdout is made null somewhere. But if that is true, why would that still be the case after overriding the main function in a win32 form app?

 

Bottom line. It can be done, and this is how you do it.

[PlausiblyDamp]

I've been playing around with this on and off for the last week or so (one of those nagging problems that won't go away...)

The only problem i found with this method is the console is always visible behind the form itself.

[Hamburger1984]

Hi!

 

....ladys and gentlemen... we proudly present... : the solution! http://www.xtremedotnettalk.com/images/smilies/cool.gif http://www.xtremedotnettalk.com/images/smilies/biggrin.gif

 

see attached test-project! should solve the problem.

 

Hope this helps!

 

Andreas

TwoApps.zip

Edited June 2, 2004 by PlausiblyDamp

[PlausiblyDamp]

Glad to see you got a solution, nice work.

[mskeel]

Thank you for the help.

 

On problem though...The sample code works great in the Visual Studio Environment, but not the same through normal command line execution outside of Visual Studio. Thinking about it a little more, it is a good idea to hide the command prompt when the form launces. This isn't Linux afterall...

 

Any thoughts?

[mskeel]

After a little more investigation, it does work when you run it through the Run menu. And everything works beautifully. I guess it would be unrealistic to close a command prompt the user open themselves. To cover this case, the program should execute in a seperate thread so as not to keep control of the command prompt while the prgram executes..(try running calc via command line).

 

The only other thing that would make this completely slick would be not flashing the command prompt just before GUI...it it all just worked. There may be some other work arounds for that or different ways to make that happen.

 

Thank you very much.. Excellent work.