in my mainwindow.cpp, inside the constructor, I started a qprocess so the process(.exe) runs when I open the qt application.
Now I want to kill/close the qprocess when I close the qt application. How can I do it?
See the documentation for QProcess::terminate and QProcess::kill. They each have slightly different behavior. Use terminate to give the process a chance to shut down gracefully. Use kill to kill it more forcefully. In the case of terminate, you probably want to wait until the child process has finished (e.g. QProcess::waitForFinished) before exiting the parent process.
Related
I created one GUI having two buttons. one is start button and the other is stop button. when start is pressed the program will execute in the background and the gui will freeze. I couldn't control the window anymore. even a mouse click is not responding. the stop button is for stopping the program. since the window is not responding as it is running the program i cant press stop. what is the possible solution? .please help
A thread is sort of a subprogram inside your program. When the application starts it runs in the main thread. You can create many other threads; all of them (the main one included) share the application memory space (for example, same global vars in scope).
There are two kind of threads: "detached" and "joinable". detached threads delete themselves when they finish, think of them as "fire and forget". Conversely, joinable threads are deleted by yourself, only after they have completed their job.
In wxWidgets all GUI is executed in the main thread. Calling a GUI function from another thread is a nightmare, don't do it.
Your case is a typical situation. The "start" button launches a thread to do some job. If you want to cancel this job you push the "stop" button.
How to instruct the thread to cancel its job?
While you can use wxCondition, you can also set a flag on your own. The working thread reads at some moment this flag (it's not automagic, you must code it) and stops or continue depending on its value. Don't forget to use a wxMutex before accesing the flag to protect it from another thread changing it at the same time.
Also, threads can post messages to the main thread event-loop. This way you can tell the main thread that your worker thread has finished its job.
Threads require more attention when you're coding them. You must avoid some situations such as:
"dead lock": two threads wait one for each other, none finishes.
"race condition": several threads try to change a shared value at the same
time.
More on wxWidgets docs and thread sample.
Finally, C++11 has std::thread and other related friends (mutexes, semaphores, etc). It's your choice to use it instead of wxWidgets classes.
I have a dialog which acts as a configurator for a console application. The dialog’s job is to offer the user a set of widgets (which mirror the options supported by the console application) and when user clicks on the “Start” button, the dialog creates and starts a QProcess with the console application’s name and parameters based on the state of the widgets in the GUI. I am able to start the process successfully and everything works fine. However, when I want to kill the process, the console application needs to shutdown gracefully, meaning it has to close files, flush data, close devices etc., and then terminate.
I used QProcess::close(), this immediately kills the application and the app is unable to shutdown gracefully.
I have used the Win32 GenerateConsoleCtrlEvent(CTRL_C_EVENT, Q_PID::dwProcessId) to send an even to the same. I see that the above API returns a non-zero value (indicating a success, it would return 0 upon failure), but my process continues to run.
Can anyone help me with how I can signal the QProcess to shutdown gracefully? Or is there any other way to do this?
GenerateConsoleCtrlEvent takes a process group id, not a process id. You are likely feeding it a process id, since that's what QProcess provides.
QProcess doesn't support creation of a process group at the moment. You need to either start the process manually using winapi, or patch your copy of Qt to amend qtbase/src/corelib/io/qprocess[.h,.cpp,_win.cpp] to pass the CREATE_NEW_PROCESS_GROUP creation flag.
If you don't wish to tweak Qt itself, you can copy the qprocess files to your project, rename the class, and add the changes there.
Suppose I start a process in terminal in Linux, if the terminal is closed the child process started in terminal also exits (even if process is started using sudo). But if I start a process (say) p1 using QProcess inside a GUI application, and then close the gui application, process p1 still keeps running, as if it is a daemon, even if I don’t start the process using QProcess::startDetached().
process1->start("gksudo",args);
and
process1->terminate();
process1->close();
in closeEvent.
Try adding
delete process1;
in GUI class destructor.
How are you initializing your QProcess? When I did the following (on Windows) in mainwindow.cpp my child process closed when I closed my main application.
QProcess* proc = new QProcess(this);
proc->start("notepad.exe q:/blah2.txt");
By making MainWindow a parent of QProcess, MainWindow will destroy and close it during its QObject destructor.
I have a Qt program that is using the QtConcurrent API to spawn worker threads. The problem I am having is that the worker threads keep going even if I exit the Qt application.
I have an actionExit in my menu, which is what i am using to close the app, or the "X" in the window corner. Is there any way to make these kill off all threads related to this app?
Thanks
Are you sure that the UI application really closes? You might be missing:
qApp->setQuitOnLastWindowClosed(true);
Otherwise QT only hides your window. To debug put a breakpoint behind your
mainWindow->exec(); and see whether it is really reached.
If you confirm that exec() returns and QTConcurrent really hangs (it might be possible: http://lists.trolltech.com/qt-interest/2008-06/thread00414-0.html), then do:
exit(0);
I guess the question says it all, but, what happens if someone closes a c++ console app? As in, clicks the "x" in the top corner. Does it instantly close? Does it throw some sort of exception? Is it undefined behavior?
Closing a c++ console app with the "x" in the top corner throws an CTRL_CLOSE_EVENT which you could catch and process if you set a control handler using the SetConsoleCtrlHandler function. In there you could override the close functionality and perform whatever you wished to do, and then optionally still perform the default behavior.
I imagine that the console process just gets unceremoniously killed by the OS. If you want to trap this event and do something it looks like the SetConsoleCtrlHandler function is the way to do it.
See also:
How to handle a ctrl-break signal in a command line interface
Console Event Handling
On Linux and other Unix systems, the console runs as a separate process. As you close the shell, it sends the SIGHUP signal to the currently active process or processes that are not executed in the background. If the programmer does not handle it, the process simply terminates. The same signal is sent if you close the SSH session with a terminal and an active process.
SIGBREAK is raised on Windows.