Both a command line and GUI application at the same time?

[agarny]

Hi,

I have a GUI application to which I would like to add command line support. Basically, if I was, from a command prompt, to enter something like

$ ./myApp

then the GUI would just show up. However, if I was to enter something like

$ ./myApp -i myInputFile -o myOutputFile

then my application would execute in 'silence', i.e. without the GUI ever showing up.

I thought I would use the QxtCommandOptions class (from LibQxt) to do this, but the only way I have got that class to work was by having a 'pure' Qt console application. As soon as the Qt application is a GUI application, then I am not able to use the class.

Any idea of what I might be doing wrong or what I would need to do get what I am after?

EDIT: I can do what I am after on Linux (and, I would assume, on Mac OS X), but not on Windows and I believe this is due to the way Windows handles console applications. Still working on finding a solution though...

[HeReSY]

You can check your Gui-App. If it has parameters you hide it, else you show it.

[agarny]

You can check your Gui-App. If it has parameters you hide it, else you show it.

Thanks, but..

1. I wouldn't want to have to reinvent the wheel and would therefore like to be able to use QxtCommandOptions or something similar which could handle command line options for me; and
2. I would like to be able to output some text to the console and I haven't been able to do that using std::cout from a GUI Qt application, but then again maybe it's not supposed to work and/or it should be done in a different way with a GUI Qt application?

[arnaiz]

Maybe you can use hide() to hide your main window. Now you can process the input parameters as usual, but without a GUI showing up...

Is this what you are looking for?

[high_flyer]

Maybe its just me I don't understand what the problem is.
You application get argumens every time it starts (GUI or not):

int main(int argc, char *argv[])
{
	QApplication a(argc, argv);
...
}

int main(int argc, char *argv[])
{
	QApplication a(argc, argv);
...
}

To copy to clipboard, switch view to plain text mode 

just parse the arguments and start the application any way you want to (with or without GUI).

If someone will call the application from the console with arguments, the you can do with them something, or with a double click on the exe, then the arguments are empty.

[agarny]

high_flyer, you are correct and I have got things to work the way I want on Linux (and most likely on Mac OS X too) using the following code:

int main(int pArgc, char *pArgv[])
{
    QtSingleApplication app(pArgc, pArgv);
 
    // Handle the command line options, if any
 
    QxtCommandOptions options;
 
    options.add("help", "Show this help text");
    options.alias("help", "h");
 
    options.parse(app.arguments());
 
    if(options.count("help") || options.showUnrecognizedWarning())
    {
        options.showUsage();
 
        return -1;
    }
 
    ...
 
    // Execute the application
 
    return app.exec();
}

int main(int pArgc, char *pArgv[])
{
    QtSingleApplication app(pArgc, pArgv);

    // Handle the command line options, if any

    QxtCommandOptions options;

    options.add("help", "Show this help text");
    options.alias("help", "h");

    options.parse(app.arguments());

    if(options.count("help") || options.showUnrecognizedWarning())
    {
        options.showUsage();

        return -1;
    }

    ...

    // Execute the application

    return app.exec();
}

To copy to clipboard, switch view to plain text mode 

It's just that on Windows, a GUI application cannot directly write to the console (unless your application is a pure console application which mine clearly isn't) and

options.showUsage();

options.showUsage();

To copy to clipboard, switch view to plain text mode 

above will therefore never output anything while it does on Linux.

Now, I had a quick look at the Windows API and it would seem that one might be able to do work around this issue by attaching a console to the GUI application:

#ifdef Q_WS_WIN
    #define _WIN32_WINNT 0x0501   // I.e. Windows XP and higher
 
    #include <windows.h>
#endif
 
...
 
int main(int pArgc, char *pArgv[])
{
    ...
 
    if(options.count("help") || options.showUnrecognizedWarning())
    {
#ifdef Q_WS_WIN
        AttachConsole(ATTACH_PARENT_PROCESS);
 
        // Some calls to WriteConsole to simulate the call to options.showUsage() which
        // works perfectly fine on Linux but not on bloody Windows!
#else
        options.showUsage();
#endif
 
        return -1;
    }
 
    ...
}

#ifdef Q_WS_WIN
    #define _WIN32_WINNT 0x0501   // I.e. Windows XP and higher

    #include <windows.h>
#endif

...

int main(int pArgc, char *pArgv[])
{
    ...

    if(options.count("help") || options.showUnrecognizedWarning())
    {
#ifdef Q_WS_WIN
        AttachConsole(ATTACH_PARENT_PROCESS);

        // Some calls to WriteConsole to simulate the call to options.showUsage() which
        // works perfectly fine on Linux but not on bloody Windows!
#else
        options.showUsage();
#endif

        return -1;
    }

    ...
}

To copy to clipboard, switch view to plain text mode 

The problem with the above is that it's really ugly and very much looks like a big hack to get around Windows' stupid limitation.

[high_flyer]

If you are using MSVS just set Linker->system->console. - and it will add a console window to which your application can output.

[arnaiz]

Also you can add console to the CONFIG line in your project file. No need to make simple things complex...

[agarny]

Sorry, I guess I should have made it clear that I do NOT want the console window to be visible at all times, ONLY if there is a need for it, i.e. when arguments passed to my application require output to the console. (Otherwise, I don't use QMake, but CMake and this not with MSVS but with MinGW )

[high_flyer]

If what you need is only an output window, then just make one using widgets - I don't know if its possible to call a console window in runtime, and associating it with your application for output in any cross platform way.
For startup arguments you will have to have console before your application starts any way.

[agarny]

If what you need is only an output window, then just make one using widgets - I don't know if its possible to call a console window in runtime, and associating it with your application for output in any cross platform way.

It's not only an output window that I need. I really need access to the console. On Linux, for example, one might want to redirect the output to a file or something. If I was to create an output window, I couldn't do that.

For startup arguments you will have to have console before your application starts any way.

Not sure what you mean by this...

[arnaiz]

Again, you can hide() your main window, so there is no GUI showing up, and then you can use a QProcess to execute the command processor of your OS. You can use readData() and writeData() for your IO.

Now you can control your GUI, use objects already written, open a console if you need to, and read or write from that process. Is this an option to solve your problem?

[agarny]

Again, you can hide() your main window, so there is no GUI showing up, and then you can use a QProcess to execute the command processor of your OS. You can use readData() and writeData() for your IO.

Now you can control your GUI, use objects already written, open a console if you need to, and read or write from that process. Is this an option to solve your problem?

I get the feeling that we are not understanding one another. As I said, everything works as I expect on Linux and Mac OS X (I have just checked), so let me explain a bit more what is 'wrong' with Windows.

Ok, say that you open a command prompt window. From there, if I enter the name of my application without any argument, then I want the GUI to show up (easy, since it's already the way it works):

C:\MyApplicationDirectory>MyApplication

C:\MyApplicationDirectory>

Now, say that I add some arguments. This time round, I want my application to behave as a pure console application, so that I can do whatever I want with it (e.g. redirect the output to a file):

C:\MyApplicationDirectory>MyApplication /i myInputFile
MyApplication is going to proceed using myInputFile as an input file
...

C:\MyApplicationDirectory>

Now, as I have said in a previous reply, I can use AttachConsole() and WriteConsole() to 'mimick' the above output, but 1) it's a hack and 2) I can't get the right kind of output (and I am not sure whether I could redirect to a file; I haven't tried) since when starting a GUI application from the command line, Windows goes back to the prompt straightaway, so if anything using AttachConsole() and WriteConsole() I could get:

C:\MyApplicationDirectory>MyApplication /i myInputFile
C:\MyApplicationDirectory>
MyApplication is going to proceed using myInputFile as an input file
...

which is clearly not professional...

[high_flyer]

It's not only an output window that I need. I really need access to the console.

I don't understand how you mean that.
Lets say you have an open console, and you start you application with arguments.
Your application starts, and outputs to the console - now you want in that very output console interact with the application??
Or do yo mean you want your application to spawn two consoles, one for input and one for output?

Not sure what you mean by this...

Well, how do you suppose you can start an application with arguments with out a console?

[agarny]

I don't understand how you mean that.
Lets say you have an open console, and you start you application with arguments.
Your application starts, and outputs to the console - now you want in that very output console interact with the application??
Or do yo mean you want your application to spawn two consoles, one for input and one for output?

As you said, let's say that I have an open console. Now, what I would like is that if I start my application from that console, but with no argument, then I just want the GUI to show up. However, if from that same console window, I start my application with some arguments, then I want my application to take advantage of the console and interact with it (for output only, since I wouldn't expect to need it for input, though one can never tell for certain), and this is where my problem lies... I can't seem to be able to do that in a neat way on Windows while it all works fine on Linux and Mac OS X (even though I do get to see the application icon popping up temporarily on Mac OS X, but I am 'OK' with it I suppose).

Well, how do you suppose you can start an application with arguments with out a console?

Well, you can always create a shortcut which points to your application and which has arguments associated with it, but this might be besides the point indeed.

[agarny]

I had never noticed this: QApplication::QApplication ( int & argc, char ** argv, bool GUIenabled ). Now, if only it was working on all three platforms... Argh!

[high_flyer]

Now I learned something new too!

Now, if only it was working on all three platforms... Argh!

Where does it say that it doesn't?
It only says that on Windoes and Mac the windowing system is intialized, but that is not a a problem for you.

Also, I don't see how this actually solvers your problem of spawning a console...

[agarny]

Well, I gave it a try and when I tried to write something to the console, e.g.

std::cout << "Hello World!" << std::endl;

std::cout << "Hello World!" << std::endl;

To copy to clipboard, switch view to plain text mode 

it just didn't work while it (obviously) does when the application is a pure console application.

[agarny]

Okie dokie, I have finally got a solution which I am happy with...

Basically, on Windows, an application can either be a console application or a GUI application, not both. There is no way around that. However, yesterday evening, I found an old MSN magazine article about making a 'hybrid' console/GUI application. Basically, the trick consists of having a .com and a .exe version of your executable (gosh, I had completely forgotten about the .com trick!). The .com is a console application while the .exe a GUI one. Note that it's not the same as having both a console and a GUI version of your application, since for most people this would likely involve two .exe files, e.g. myAppConsole.exe and myAppGUI.exe, which is clearly not what one would ideally want. Consider indeed the case where you a console window is opened. Well, you don't want to have to decide between myAppConsole.exe and myAppGUI.exe. Instead you would just like to be able to enter something like:

C:\>myApp

C:\>myApp

To copy to clipboard, switch view to plain text mode 

and that is it, and that's where having both a .com and a .exe version of your application (i.e. myApp.com and myApp.exe) comes in very handy.

Anyway, all that to say that I have just implemented this in Qt and it all works like a charm. I have attached the source code and binary version of that small Qt application (HybridConsoleGUIApplication.zip; note that I have left my .pro.user file since I do a tiny bit of post-processing), in case people wanted to do something similar. When unzipping the file, you will get a ListProc folder. In it, you will find a Bin folder which contains both ListProc.com and ListProc.exe. Open a console window, go to that Bin directory and you should be able to reproduce what follows:

C:\Users\Alan\Desktop\ListProc\Bin>ListProc -h
Usage: ListProc [-c]
 -c Console mode
 
C:\Users\Alan\Desktop\ListProc\Bin>ListProc -c
Processes:
 - Processus #1...
 - Processus #2...
 - Processus #3...
 - Processus #4...
 - Processus #5...
 - Processus #6...
 - Processus #7...
 - Processus #8...
 - Processus #9...
 - Processus #10...
 
C:\Users\Alan\Desktop\ListProc\Bin>ListProc
 
C:\Users\Alan\Desktop\ListProc\Bin>

C:\Users\Alan\Desktop\ListProc\Bin>ListProc -h
Usage: ListProc [-c]
 -c Console mode

C:\Users\Alan\Desktop\ListProc\Bin>ListProc -c
Processes:
 - Processus #1...
 - Processus #2...
 - Processus #3...
 - Processus #4...
 - Processus #5...
 - Processus #6...
 - Processus #7...
 - Processus #8...
 - Processus #9...
 - Processus #10...

C:\Users\Alan\Desktop\ListProc\Bin>ListProc

C:\Users\Alan\Desktop\ListProc\Bin>

To copy to clipboard, switch view to plain text mode 

Following the last call to the program, the GUI version of the application should show up.

So, yes, very simple in the end... that is, when you know how to do it!

[high_flyer]

Basically, on Windows, an application can either be a console application or a GUI application, not both. There is no way around that.

That is not true, at least for sure not true for output.
I have added consoles to my GUI's, with the MSVS Linker settings I suggested at post #7, but only used it for output, not for input, so I don't know about input, although I don't see a reason why input should work as well.
I never really looked beyond to see what this setting does under the hood to the project arguments, but I leave it to you as an exercise