I have a GUI program that opens a Windows console in a separate window to display output and accept user input. My development environment is Qt 4.7.1 with mingw. The console works fine, until I try to run the program in Qt's debugger (gdb); then, although AllocConsole succeeds, and GetStdHandle appears to return a valid handle (0x000000d8), any attempt to use the handle causes Windows error 6 (invalid handle).
So I can't debug my program. Which is a pain, because it has some serious bugs. The problem may be that gdb's console prevents me opening my own console; but then why do AllocConsole and GetStdHandle succeed? I upgraded to Qt Creator 2.0.94 (Qt 4.7.1), but it didn't help. Any ideas?
Update I have found that I can debug the program by running it without the debugger, and then attaching to it from Qt. Not ideal, but better than nothing.
Can't you use the standard output console, using
CONFIG += console
in the .pro file?
Hmm -- check this out:
A process can be associated with only one console, so the AllocConsole function fails if the calling process already has a console. A process can use the FreeConsole function to detach itself from its current console, then it can call AllocConsole to create a new console or AttachConsole to attach to another console.
Can you try running FreeConsole before you create yours?
Related
When running my Qt5 application on linux, I don't see any output from qDebug, qWarning, qCritical or qFatal. I know that I can use qInstallMsgHandler to install a message handler and see them, but this is rather heavyweight.
I just want to check the qWarning log to see if there is any signal that mis-connected. Is there a way to look at this log? A special command-line option, an environment variable?
I think I remember that in the past, everything was printed to stderr, perhaps that's a Qt5 change?
Please do not make the mistake of assuming that qDebug, qWarning, qCritical and qFatal always log on standard error. That's absolutely not the case.
The actual destination varies depending on the Qt configuration and the targeting OS. Plus, 5.4 and then 5.11 introduced some behavioural changes. See here and here for discussions.
TL;DR:
On Qt >= 5.11
If the process' stderr has a console attached, that's where the debug log will go.
If you want to always log on stderr, set QT_FORCE_STDERR_LOGGING to 1.
In alternative, set QT_ASSUME_STDERR_HAS_CONSOLE to 1. I suspect this one is meant to be used by a parent process that reads a child's stderr and shows it to the user somehow.
QT_LOGGING_TO_CONSOLE to 1 still works, but Qt will complain.
On Qt >= 5.4 and < 5.11
If you want to always log on stderr, set the QT_LOGGING_TO_CONSOLE environment variable to 1.
If you do not want to log on stderr, the QT_LOGGING_TO_CONSOLE environment variable to 0 (this will force logging through the native system logger).
If the QT_LOGGING_TO_CONSOLE environment variable is not set, then whether logging to the console or not depends on whether the application is running in a TTY (on UNIX) or whether there's a console window (on Windows).
On Qt < 5.4, the situation is more confusing.
If Qt has been built with support for a specific logging framework (e.g. SLOG2, journald, Android log, etc.) then logging always goes to that framework
Otherwise on UNIX it goes to stderr
Otherwise on Windows OutputDebugString or stderr is used depending whether the app is a console app.
The problem with the pre-5.4 approach was that, f.i., under Unix IDEs would not capture an application's debug output if Qt had been built with journald support. That's because the output went to journald, not to the IDE. In 5.4 the approach has been made more flexible and uniform across OSes.
If you happen to run Arch Linux, which compiles Qt with the -journald option, all debug output is per default directed to the systemd journal (display with journalctl).
You can override this behaviour by defining QT_LOGGING_TO_CONSOLE=1 as an environment variable.
They are still printed to standard error.
If you launch the application from the command line, it is usually printed there, or if using Qt Creator, it's displayed in the Application Output window.
If you are using visual studio, qDebug etc are printed to the output window in the IDE.
I understood that anything to standard out (System.out) would appear in the Java Console window (when it's enabled). I spotted somewhere though that there might be situations where this isn't try, for example, from Swing apps. Is that the case?
Basically, what situations or setups wouldn't I expect to see standard output in the console? Is there a difference in behavior running on the JDK rather than explicitly on the JRE for example? javaw.exe?
ps, I understand how to display the Console in the Java settings but I'm curious as I've managed to create an application, run as an executable jar, that doesn't start the console despite some calls to System.out) on Windows 7.
The only way you wouldn't see System.out output in the console is if the method System.setOut has been invoked. This method is invoked to redirect output to the graphical Java Console, but I don't know of any other realistic circumstance in which it would be redirected away from the Java Console unless you do so voluntarily.
Depending on terminal settings it can happen that the output is not written until a newline character is sent as well. So if you do System.out.print("test") it might not appear immediately.
On Windows this is usually not the case, but on Unix terminals this is quite common.
Perhaps you use javaw to start virtual machine, this version will not show console messages. You can use java to start the virtual machine, which will show the console message.
javaw is intended for apps with windows, java is intended for console apps.
Same thing happened to me. I could not get System.out.println or Logger.debug either on console.
If you are on a huge project in Eclipse or whatever, you can read below.
Solution: I realized that I had not committed jars and some java files to SubVersioN on network. thats all. Project had not been compiled.
One situation I can think of is to invoke System.setOut(null) (orSystem.setOut(any OutputStream other than System.out or System.err)) then the console, if exists, would show nothing.
I have a small app that I'm trying to build against windows machines. The program creates an OpenVPN connection. If I build the program and run it it first opens a console as the program output. If I pass the -w parameter to pyinstaller to not build it with a console attached the program fails to run at all. It opens allright but the vpn connection is never created.
With the console everything works perfect.
I also have a basic logging for the application in place to see where my code might stop and nothing gets written. With console on my program spits out all kinds of logs.
I just don't know why my program could be performing perfectly with a console but doing nothing without one. Any ideas?
Gonna answer this myself. Make sure you don't print anything and also you redirect all stdout to a logger, file or whatever else instead of the console.
I was having a similar problem, but couldn't find any print/stdout statements going to console. I was using subprocess.Popen and redirecting stdout=subprocess.PIPE. I subsequently added stderr=subprocess.STDOUT and stdin=subprocess.PIPE and my program worked. This page (Python subprocess.call() fails when using pythonw.exe) on subprocess failures helped me get it working.
Is there a possible way to attach the console to a GUI so that the user will be able to enter commands into the console from the GUI?
As long as the program is launched from the console, it can read and write from/to the console. There's nothing that makes a Java program "GUI" or "Console" except for the code.
If you want to always have a console regardless of how the program is launched, you could just code a frame to behave as one.
I compile my qt-project with += console option,
I need it to debug version, and for release I rebuild
project with -= console
But sometimes I need enable\show console output in release version of my app.
So my question is - Is it possible to pass some argument (line -show_console) to
my .exe to start app with console or without (if no option specified)?
I have an application with a GUI window and a console window. I open the console window using AllocConsole from the Windows API. The trouble is, Qt can't debug it, at least using gdb, because gdb needs a console too. But see my question here for a workaround.
If you mean you want a gui app that also writes to the console then under windows you need to reopen the console.
Alternatively - Set the application type to console ( ie /subsystem:console in windows) but still write the normal Qt gui code, it will open a console and you can use std::cout