If I run a Qt application directly from the Windows command-line (cmd), it immediately returns back to the shell even as the GUI continues running; I assume it creates a second process before the parent exits.
If I run the Qt application indirectly though, from a batch file or Python script, it doesn't behave the same way; it blocks until the application actually exits:
Is this standard Qt behavior? I can't find any mention of it in the documentation or anywhere else. Can it be customized? I would prefer that the application always block when run from the command-line.
This is NORMAL Windows behavior.
In a console console programs are waited on. GUI programs are not. The rules are specified in start /?(mention of new behavior is NT4 to Windows 2000).
So Start /w c:\windows\notepad.
Related
I am attempting to use QTCreator's Memcheck tool to analyze the memory of a QT project, which is a dynamic library. It uses a QT Gui (QMainWindow) to allow the user to select a file, which is then processed, and then eventually returns to the mainwindow.
However, I cannot seem to use Memcheck properly.
When I select "Memcheck" and hit run, it instantly goes to "Analyzing memory" without ever letting the Gui pop up.
This is problematic. How can I get memcheck to work with this program?
I had two main issues:
1: Valgrind does not seem to play nice with QT Gui applications. It generates logs that are thousands of entries long for all the work QT is doing before it even gets to my application.
I had to make a separate, small non-GUI C++ program that would drive instead of the GUI application.
2: When trying to run from the command line, I needed to set an environment variable by using export. This needs to be the same as LD_LIBRARY_PATHS in QT Creator.
So I ran:
export LD_LIBRARY_PATH=X where X was the exact value I copied from LD_LIBRARY_PATHS in the variable from the QT Project.
Note: Running from the command line may have not be neccesary now that it isn't a GUI Application, memcheck might have passed just fine. Haven't tested since.
I have a GUI application which contains a websocket server QWebSocketServer. I also have a python script which sends messages and the application processes them. Everything works well. During testing I wanted to run the application in headless mode using -platform offscreen command line argument added to the app executable name (I changed nothing else). But the problem is that when the application runs off-screen, the client script cannot establish connection with the web socket server. I tested this on localhost only. I do not understand how this two things, visibility of GUI and websockets, can interfere. Any ideas what could go wrong?
Note: I am using Qt 5.11.1 64-bit with VS 2017 on Windows 10 Pro.
A platform plugin is a bit more than merely "GUI". The -platform option selects a family of platform-specific plugins. Perhaps some plugins that make networking work are absent on that platform spec. That's very likely, since the offscreen platform is only a proof-of-concept: it's to show how you'd write a platform plugin. It's example code, and it does the bare minimum needed. It's nothing that you should be using for production without fully understanding what's there and how it works - it wasn't not meant for it, at least not the last time I looked at it. It shouldn't be hard to make it work, but you'd need to clone the source and start hacking on it.
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.
Using OpenJDK 7 from the command line on OS X Lion, how can I use jdb to debug an application that requires execution under a 32-bit JVM, due to JNI native code?
I know I can invoke java as java -d32 and it will use a 32-bit JVM. I can also pass that -d32 flag to jdb without an error, but it does not seem to have any effect: I still get the same error messages when the application tries to link its native code. Passing -J-d32 exhibits the same behaviour.
It is possible to achieve the above by starting java and jdb as separate processes from two different Terminal windows. So execute these commands, each in its own window:
java -d32 -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=127.0.0.1:5463 -classpath . MainClass
jdb -attach 127.0.0.1:5463
The first will start the JVM for the application, but suspend it immediately after creation. The second will start the debugger and attach it to the JVm just created. Then you can type run in that second window to launch the application. As an added bonus, output from the application and the debugger are not intermixed, as each has its own window.
References: The jdb help lists possible command line arguments, and JPDA has a section on transports.
Although the above does work for me, I'd welcome other answers providing easier solutions, preferrably as a single command and/or without any need to choose port numbers in an arbitrary fashion. The shared memory connector does not seem to work for my JVM.
I'm using Ubuntu and Qt Creator 4
I have a .cpp program in the executable form (say abc.out) that I wish to run when I press a button. It contains a number of cin and cout, so I want it to run on a "terminal" (on Ubuntu) so that I am able to input and output values to it. How can I do that?
I've tried system() and
also,
QProcess p1;
p1.start(./abc.out);
Using QProcess, my executable runs but stops at the first cout. It runs on the application output screen in Qt Creator and not on terminal.
For example:
I see on application output:
enter name:
When I type the value and press enter here, it doesn't accept the value, but moves to the next line and allows me to type further.
I want to run this abc.out file on the terminal. Any ideas would be really helpful.
Do you mean Qt Creator 2.4? In any case, on the Projects tab, you should find the Run settings section and from there you can find a "Run in terminal" checkbox. You could also use a Custom Executable option and type there: gnome-terminal --command ./abc.out The exact details can vary a bit as I'm using Qt Creator 2.5.
This should work when launching from Qt Creator, but when you use your app outside the IDE, you need to launch it from terminal and not by double clicking the executable. To fix this, I can think of two ways:
Launch a terminal window from QtGui (something like QProcess::execute("gnome-terminal --command ./abc.out"); ), though the problem is different systems have different terminal names.
Provide a Qt input/text box yourself as part of your GUI which then forwards the user input to the executable (something like myqprocess.write(input_asked_from_user_by_QtGui); ). Here you probably need to know what information to ask the user beforehand. If you want to display the cout output of the started process, you can use the read method and friends of the QProcess.
From your question I assume that you are writing an application that launches other applications using QProcess. Thats fine, but if your subprocess is waiting for data from the standard input it will wait forever since you did not provide any data. The stdin of your parent application cannot be automatically guided to the subprocess. Imagine you are starting two processes from your main app. To which child process should the input go?
If you want to communicate with child processes, you must use the QIODevice methods of QProcess and send/read data from/to that application.
The only sensible solution is to launch the target application in a terminal. Whether your own code provides the terminal window or you reuse an existing terminal application is up to you.