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

[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

[agarny]

Of course that you can attach a console to a GUI application (as has been discussed several times in this thread!), but this is NOT what I am after!

Anyway, you don't seem to be getting (or want to get) the point I am trying to get across. So, please have a look at the article I referred to and... maybe you will finally understand what I am talking about and what I was after.

[high_flyer]

you don't seem to be getting (or want to get) the point I am trying to get across. So, please have a look at the article I referred to and... maybe you will finally understand what I am talking about and what I was after.

You should listen to your own advice.
In the link YOU provided:

OK, now that I'm off my soapbox, how can you implement a combined GUI/console app? As nearly every programmer targeting Windows knows by now, Windows divides the EXE universe into two camps: console apps and GUI apps. This architecture goes back to the earliest days of Windows, when it first evolved from MS-DOS®. Nowadays, you tell the linker which kind of app you want to generate by using a switch: either /subsystem:Windows or /subsystem:console.

Which is what I was talking about.

[agarny]

Oh god, here we go again. Let me remind you, you replied to my comment that read:

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

and you said that this was not true, implying that one could perfectly have a Windows application that is both a console and a GUI application. From your last message quoting the link I gave:

OK, now that I'm off my soapbox, how can you implement a combined GUI/console app? As nearly every programmer targeting Windows knows by now, Windows divides the EXE universe into two camps: console apps and GUI apps. This architecture goes back to the earliest days of Windows, when it first evolved from MS-DOS®. Nowadays, you tell the linker which kind of app you want to generate by using a switch: either /subsystem:Windows or /subsystem:console.

Now, unless I am mistaken this confirms what I said above which was, in fact, nothing more than me paraphrasing the author of the old MSDN magazine article I referenced:

In short, a Windows-based app must be either a console app or a GUI app and there's no way to have your cake and eat it too. (Unless you want to write your own startup code—which is waaaay more than I'm up for tonight!) But you know it can be done because I already told you Visual Studio does it—but how?

From what you said in comment #7, it would seem that one can associate a console to a GUI application, and I am very happy to believe that. So, yes, you are 'right', but only in some way since I wouldn't imagine that the linker was supposed to ever be used in that way, and the fact that it can be done might be more the result of a bad design than anything else. More importantly, though, my understanding is that to use both options will result in the console window being created every time and, as mentioned in comment #9, this is not at all what I want.

[ars]

I tried the following code snippet compiled with CONFIG += console set in the .pro file:

#include <QtGui>
#include <QApplication>
 
#include <iostream>
 
#include <windows.h>
 
using namespace std;
 
int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    QMainWindow w;
 
    if(argc < 2)
    {
    	cout << "GUI project" << endl;
    	FreeConsole();
    	w.show();
    }
    else
    {
    	cout << "Console project" << endl;
    	return 0;
    }
    return a.exec();
}

#include <QtGui>
#include <QApplication>

#include <iostream>

#include <windows.h>

using namespace std;

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    QMainWindow w;

    if(argc < 2)
    {
    	cout << "GUI project" << endl;
    	FreeConsole();
    	w.show();
    }
    else
    {
    	cout << "Console project" << endl;
    	return 0;
    }
    return a.exec();
}

To copy to clipboard, switch view to plain text mode 

Running from command line without arguments just opens the empty QMainWindow. The console where I called the program from shows output "Gui project".

Running from command line with an arbitrary argument just outputs "Console project" to the calling console.

Next use Explorer to start the executable. In this case, a new console and the empty QMainWindow appear. But due to the call to FreeConsole(), the new console gets removed quickly.

So if that "flickering" of the console is ok for you, this might be a solution.

[agarny]

Yes, I am aware of FreeConsole(), but that flickering is not acceptable to me (I tend to be a bit of a perfectionist when it comes to user experience). Otherwise, as the author of that old MSDN Magazine article said:

You can destroy the console by calling FreeConsole, but the console window flashes briefly, announcing to the whole world that you don't really know what you're doing.

and I must confess that I couldn't agree more!

[wysota]

Correct me if I'm wrong but you suggest to build two exactly identical applications and call one myapp.exe and the other myapp.com and then do something in your app to detect which is the case (sorry, I didn't bother to open your archive, so I'm just guessing) so that you can operate adequately, right? So how is it different from providing two binaries containing the same code but one built with subsystem:Windows and the other with subsystem:console? And what's wrong exactly with attaching a console to your running program and having a single binary?

[agarny]

You are correct in that the .com (console) and .exe (GUI) versions of the application I attached are identical. However, I just wanted to show, using Qt, what was described in that old MSDN Magazine article. At the end of the day, it's completely up to the developer to do whatever they want.

Now, having said all of that, in my project, the .com and .exe version of my application are not the same at all. In the case of Linux and Mac OS X, the .exe version (well, I am clearly using that naming convention only for convenience here!) I handle both the console and GUI side of my application. If one of the command line options is such that the GUI shouldn't be shown, then I don't show it, simple as that. Now, in the case of Windows, if the user specifically starts the .exe version, then I go straight into GUI mode (ignoring command line options, except for file names that were passed to the .exe file). However, if the user specifically starts the .com version (or do something like C:\>myApp), then I will first analyse the command line options and determine whether there is a need for a console or a GUI version of my application.

So, yes, I am anticipating (since I am still very much working on this project and, therefore, not everything is yet implemented in it) having my back-end code to be common to both the .com and .exe version of my application. I am thinking of having a flag that will let that code know whether it is being run in console or GUI mode, and therefore allow it to determine whether outputs to the console can/should be done or not.

With regards to providing two binaries, one with subsystem:console and the other with subsystem:Windows, there would, in principle, be no difference... as long as you make sure they are named myApp.com and the other myApp.exe, and as long as the .com version can switch to the .exe version if needed (see above).

The key point here, I think, is that the basename of the binaries is the same. If the basename was to be different, then there is, from an end-user's perspective, no point in having two different binaries. I mean that, as an end-user, just want to have to 'decide' which version of the application I need to run to get a console or a GUI behaviour. Indeed, that 'decision' ought to be made by the application, not the end-user.

Finally, with regards to attaching a console to my GUI (and thus having only one binary indeed), the problem is that when you use AttachConsole, you must then use WriteConsole/ReadConsole, and though I got something to 'work', it wasn't 'clean' (see comment #13), as once again mentioned in that old MSDN Magazine article:

There's a new (for Windows XP) function that would seem to be just the ticket: AttachConsole. This function lets you "attach" your program to a console window of another process. If you use the special process ID ATTACH_PARENT_CONSOLE, AttachConsole attaches to the console from which your program was invoked. Great! But there're two problems. First, AttachConsole only exists in Windows XP, so if you want your program to run in other versions of Windows, you're out of luck; and second, AttachConsole doesn't work exactly as hoped. You can write stuff to the console, but the command prompt is all messed up after your program exits—oops!

I am telling you, that article is definitely worth a read for anyone who needs their their application to be a hybrid console/GUI application.

To sum up, attaching a console is, in my view, not the way to go (as just mentioned above). Instead, one should indeed have two binaries (one .com and one .exe) with the same basename. This implies the back-end code to be shared by both binaries, but I can't see much way around this unfortunately...?