CODEWITHSUNDEEP
c#user-interfaceconsole-applicationcommand-line-interface
sara
sara

Reputation: 3934

Both CLI and GUI application

I am writing an application that has both CLI and GUI.

I read most questions and articles regarding it, and found highly usefull this question:

Can one executable be both a console and GUI application?

My final code looks like:

        if (args.Length > 0)
        {
            //console code            
        }
        else
        {
            FreeConsole();
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.Run(new Form());
        }

This works great when running the .exe by double click, or when debugging, or from console with arguments.

However, when running it from the console with no arguments, the GUI is opened, like I intended, but the console is stuck waiting for the GUI to close.

This is uncharacteristic GUI and console behavior. the console usually launch the GUI and not wait to its exit, but for new commands.

Is there is a way to avoid it?

Upvotes: 4

Views: 3949

Answers (6)

nintyfan
nintyfan

Reputation: 434

Best approach to write application working in GUI/CLI/CUI/Network mode is using libgreattao.

Search for it on sourceforge.net.

Libgreattao decouples business logic and communication mechanism, so you can put libgreattao related code everywhere in your program.

Upvotes: 0

Alberto De Caro
Alberto De Caro

Reputation: 5213

Need to start a gui application from console without stuck the console? From the command prompt type:

start "[title not necessary for gui exe]" "full path to .exe"

See here

Upvotes: 0

Louis Kottmann
Louis Kottmann

Reputation: 16618

This looks correct. You launch a command that only returns when the application is stopped.

If you don't want to wait for it to return, start it in a new thread. (ThreadPool, Thread, Task, async/await in C#5.0 => pick your favorite).

Upvotes: 0

Tony Hopkinson
Tony Hopkinson

Reputation: 20320

THe usual way to do this is to abstract presentation from logic and then have two exes, one CLI, one GUI, not to have one that could be either. Going down that route leaves you with some sort of awful compromise with the benefits of neither approach. GUI with command line options is not a CLI app, it's a GUI with an invisble / short lived window.

Upvotes: 1

Antonio Bakula
Antonio Bakula

Reputation: 20693

Maybe is not an answer to your direct question, but with this dual solution you are asking for trouble :) This is a hack that will work in some cases, but in other not.

Proper solution would be exclude functionality and application logic in separate class library and then from both console and GUI application call that "engine". Put all that three projects in one Visual Studio solution. All functionality and vast majority of code should be in that class library, GUI and console projects would only deal with that specific aspects that depends on environment (eg. button click event would only be in GUI app etc.)

Upvotes: 0

Anders Abel
Anders Abel

Reputation: 69250

The accepted answer in the question you linked to contains this passage:

Junfeng's second technique is what ildasm uses. He quotes the process that ildasm's author went through when making it run in both modes. Ultimately, here's what the it does:

The program is marked as a console-mode binary, so it always starts out with a console. This allows input and output redirection to work as normal. If the program has no console-mode command-line parameters, it re-launches itself. It's not enough to simply call FreeConsole to make the first instance cease to be a console program. That's because the process that started the program, cmd.exe, "knows" that it started a console-mode program and is waiting for the program to stop running. Calling FreeConsole would make ildasm stop using the console, but it wouldn't make the parent process start using the console.

To me it looks like the headache of having a binary trying to switch between the console subsystem and GUI subsystem (which really isn't allowed) is more effort than it's worth.

One approach would be to have a separate GUI application .exe. Whenever the console app is started without parameters it launches the GUI app and closes itself.

To prevent code duplication this probably requires all the actual logic of the application to be put in a separate class library.

Upvotes: 1

Related Questions