You are not logged in.

Dear visitor, welcome to QtForum.org. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Skizmo

Beginner

  • "Skizmo" is male
  • "Skizmo" started this thread

Posts: 16

Occupation: Senior programmer

  • Send private message

1

Thursday, September 10th 2009, 9:00am

QT GUI combined with console output

HI,

I have a GUI application that needs to generate console output if the user want to disable the GUI and use it as a console app. I know that I can add a console with Config+=console or /subsystem:console. The problem is that if I do that, I ALWAYS get a console. This is not desirable when the app is run with a GUI. I found FreeConsole to remove the console but this is windows only and my app needs to be multi-platform. Is there any way to fix this problem ?

Junior

Professional

  • "Junior" is male

Posts: 1,613

Location: San Antonio, TX USA

Occupation: Senior Secure Systems Engineer

  • Send private message

2

Thursday, September 10th 2009, 2:05pm

Skizmo,

Not that I'm aware of, even the example of QApplication constructor passing it the Non-Gui flag shows to launch separate applications based on system tests.
If I'm understanding your designer correctly that is:

Pseudo:
APP ->
- GUI
-> NON-GUI
- NON-GUI

Seems from a starting app you could go either route GUI or Non-Gui based on conditions, if your in a GUI then you could QProcess off a non-Gui and close the GUI. Other than that, I'm not sure how you would do this.

Junior

Skizmo

Beginner

  • "Skizmo" is male
  • "Skizmo" started this thread

Posts: 16

Occupation: Senior programmer

  • Send private message

3

Thursday, September 10th 2009, 2:34pm

What I have now is this.

Source code

1
2
3
4
5
6
7
8
9
10
11
int main ()
{
  if (commandline doesn't contains option '/nogui')
    {
 	   show GUI and do stuff as normal
    }
    else
    {
    	run core part of program and trace result with printf/cout
    }
}

Apparently if your app is build with a GUI it isn't possible to print data to a console. It seems that his problem only occurs on the Windows platform so I added a #ifdef for windows only. In the #ifdef I tried 'AttachConsole' in the second part of the 'if' statement to attach the current console to my program. This works fine but it doesn't give me any output.

Junior

Professional

  • "Junior" is male

Posts: 1,613

Location: San Antonio, TX USA

Occupation: Senior Secure Systems Engineer

  • Send private message

4

Thursday, September 10th 2009, 2:57pm

Skizmo,

Probably not worth much, but I found this interesting..

void qDebug ( const char * msg, ... )

Calls the message handler with the debug message msg. If no message handler has been installed, the message is printed to stderr. Under Windows, the message is sent to the console, if it is a console application; otherwise, it is sent to the debugger. This function does nothing if QT_NO_DEBUG_OUTPUT was defined during compilation.

Supposedly under windows in console mode it does go to the console using qDebug; If you could check out the source for qdebug.h/cpp I wonder if you might be able to emulate something similiar. Just a thought.

5

Saturday, October 9th 2010, 10:19am

I'm also interested in a very similar thing for 3 purposes:

1) I want to write a Windows GUI application that can optionally write debug and error messages to the console. For example if the application fails to initialize, it shall be able to display an error message on the console (when executed within a cmd window). But I do not want to see a console window, when the program gets executed from the start menu in GUI mode.

2) When the user executes the program within a cmd window with a help option (such as myprogram.exe --help), I want to write that help to the console. Some GUI examples from Nokia display the help text in a Dialog box that pops up, which I find very un-natural.

3) Beneath interactive GUI mode, I want to be able to run the program in non-interactve mode using command-line options. In this case, the program shall not display any GUI, but it should write its output to the console. This is specially useful to integrate the program into batch files or to run it as a windows service.

One example where this makes really sense is the well known program ProjectX (written in Java). It normally starts with a GUI, where the user selects Video files for input and clicks on a "Start" button, which processes the input files and generates an output file. The same can also be done without GUI on the command line, just by providing filenames as command-line arguments. I use this program together with some other command-line driven programs within a batch script to process and burn TV mpeg streams onto Video DVD.

Another example is the program Gimp, which is a GUI image editor but can also manipulate images on command-line level. By the way, I noticed that (different to Linux), the windows version of Gimp contains two executables one with GUI and another one without GUI.

In the windows.h there is a FreeConsole() function which closes the unwanted console that opens, when my program supports both GUI+console. But this does not really solve my problem, because the console first pops up, and then immediately closes. This is ugly.

Do I really need to ship twi different executables, one for GUI and another one for Command-Line?

Junior

Professional

  • "Junior" is male

Posts: 1,613

Location: San Antonio, TX USA

Occupation: Senior Secure Systems Engineer

  • Send private message

6

Saturday, October 9th 2010, 11:25am

For windows you need to update the CONFIGoption in the project (.pro) file to get console output from your app.

e.g. CONFIG += qt console

Then it would be a matter of just showing/hiding widgets based on a flag you determine from an option through argv or maybe a setting in your application. Lots of ways to do that.