I have a GUI implemented with QT. The GUI has many buttons and one of them executes a shell script:
system("/bin/sh executeScene.sh");
The script is executed properly but, the GUI is blocked until I close the script that was previously called. Is there a way to execute my shell script without blocking the GUI?
The GUI has another button to stop the shell script but, as the GUI is blocked, I cannot stop the script.
Use QProcess to run the process asynchronously.
hye, i used this for one of my GUI applications...
void MainWindow::on_pushButton_clicked()
{
QProcess process;
process.startDetached("/bin/sh", QStringList()<< "/path/to/your/shell.sh");
}
Related
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.
I have developed an application which comprises of a frontend Qt-GUI and a solver EXE. As these two are independent module, I could successfully launch EXE in Qt-GUI by using a QProcess like below:
QProcess *myProcess = new QProcess;
myProcess->start(exeFilePath, args);
Where
exeFilePath = "EXE"
args = "input1 -option1 name1 -option2 name2"
From QProcess's signals, I could successfully read from output channels and update the progress in a Qt-GUI's QGLWidget.
Things have changed by time. EXE is now MPI-EXE, an MPI based executable and I need to use it through Qt-GUI in a practical way.
I tried the above QProcess exercise for MPI-EXE with the following change:
exeFilePath = "mpirun -np 4 MPI-EXE"
When doing this, myProcess could not be started and when error was printed, it gave UnknownError. As I understand, QProcess itself runs in a separate thread and from this I have to launch a 4-process MPI-EXE which makes this problematic.
I need help in :
How can I launch MPI-EXE without Qt-GUI freezing ?
How can I monitor progress of MPI-EXE as I have to plot the progress in QGLWidget ?
I will really appreciate any comments on my questions.
Please help. Thanks.
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 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?
How can I make console program disappear and work in the background?
I mean, I don't want to see the program, but I want to see it running in the task manager.
Thanks.
Assuming Windows and .NET:
You could set its output type to "Windows Application", and it will not open the console window....
Or you could create a Windows Service...
You could alternatively make one that goes to the system tray. This would also allow you to add a Kill Process directly from the system tray instead of going to the task manager. In .NET I have used the following:
http://www.developer.com/net/csharp/article.php/3336751
This may offer a few advantages.
Assuming a MS Windows XP environment:
My suggestion would be to consider making a Windows Service to do what you are asking, though another possibility would be to set something up within msconfig to run the program at startup or in the startup group within the "Start->All Programs->StartUp" section.
If you are on a Mac, Linux or some other O/S, there may exist a similar function to act as a place to run programs within the background.
If you are using Windows try
start command.exe
If you are using *nix
nohup command
Assuming you cannot modify the console application and make it a windowless application you could create a windowless application that launches the console program and redirects all the standard input and output streams to "dummy" streams.
On Windows use ShowWindow(FindWindowA("ConsoleWindowClass", NULL), false) to hide the console window. It will still be running in the background and is not visible on the taskbar.
However you will have to run a task manager like Taskmgr.exe to find it and shut it down.
#include <windows.h>
#include <iostream>
using namespace std;
int main () {
ShowWindow(FindWindowA("ConsoleWindowClass", NULL), false);
while(true) {
// Do your hidden stuff here
}
return 0;
}