i have simple application that start QDialog from its main like this :
int main(int argc, char *argv[])
{
Q_INIT_RESOURCE(resources);
QApplication app(argc, argv);
QCoreApplication::setApplicationName(APP_NAME);
QCoreApplication::setApplicationVersion(APP_VERISON);
QCoreApplication::setOrganizationDomain(APP_DOMAIN);
app.setStyle("WindowsXP");
QTextCodec::setCodecForTr(QTextCodec::codecForName("utf8"));
QTextCodec::setCodecForCStrings(QTextCodec::codecForName("UTF-8"));
AuthenticationDialogContainer *pAuthenticationDialogContainer = new AuthenticationDialogContainer();
if(pAuthenticationDialogContainer->exec() != QDialog::Accepted ) {
return 0;
}
return app.exec();
}
when its pass the end of the application that is after app.exec() and the application doing what is suppose to do . when i open the windows xp task manager i see that the process is still in memory and i need manually kill it . how can i prevent it from happening ?
QDialog::exec is a blocking call: this code show and close the dialog before the QApplication start.
You can use QDialog::show and handle the return code in QDialog::accept method.
Related
My class names is like (what it does)_(type) for example: reg_QDialog
Here is code of an executing dlg and if Accepted creating QMainWindow:
if(log_dlg->exec() == QDialog::Accepted)
{
find_wnd = new find_QMainWindow();
find_wnd->show();
}
log_dlg has 2 btns: "Enter" (here is the accept result) and "Reg" (opens a new dlg)
"Enter" and "Reg" code is here:
void log_QDialog::on_btn_enter_clicked()
{
this->accept();
}
void log_QDialog::on_btn_reg_clicked()
{
reg_QDialog *reg_dlg = new reg_QDialog();
this->hide();
if(reg_wnd->exec() == QDialog::Accepted)
{
//code
}
this->show();
}
So, here is the problem:
Step by step:
1) run the prog //it starts with dlg_log
2) "Reg" //creating dlg_reg
3) accept dlg_reg //returning to dlg_log
4) "Enter" //trying to create QMainWindow
QMainWindow is not created, and the app just closed
After "returning"(it's, actually, just hiding and then showing) from the reg_dlg and pushing btn with accept result it does nothing! It just closes the programm, but it had to show QMainWindow!
All real code of main.cpp:
#include "log_window_root.h"
#include "find_mainwindow.h"
#include <QApplication>
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
log_window_root * log_wnd;
find_mainwindow * find_wnd;
log_wnd = new log_window_root();
log_wnd->setWindowFlags(Qt::Dialog | Qt::MSWindowsFixedSizeDialogHint);
log_wnd->setModal(true);
if(log_wnd->exec() == QDialog::Accepted)
{
find_wnd = new find_mainwindow();
find_wnd->setWindowFlags(Qt::MSWindowsFixedSizeDialogHint);
find_wnd->show();
}
return a.exec();
}
You are a operating a bit beyond the limits of Qt. Looking at the documentation:
Generally, no user interaction can take place before calling exec().
As a special case, modal widgets like QMessageBox can be used before
calling exec(), because modal widgets call exec() to start a local
event loop.
Testing your code on Mac OS will give you the dreaded warning
modalSession has been exited prematurely - check for a reentrant call
to endModalSession
which shows, that you are working on thin ice and your code will break any time.
Consider reworking your code so that the MainWindow comes up and then show your dialogs. If you want to go on with the Dialog sequence, then remove the hide()/show() pair from on_btn_reg_clicked (these calls mess up your event loops).
QApplication exits and close when the last window has been closed.
You can discard this by setting QApplication::quitOnLastWindowClosed property to false.
QApplication a(argc, argv);
a.setQuitOnLastWindowClosed(false);
You may want to revert it to it's previous state when your job is done with those dialogs.
As #Jens mentioned in the other answer to your question, this is will break evenloop at some point and QApplication exits before even a.exec() being called. So, you can also create a zero width/height or off-screen QWidget as a parent of your dialogs. A QSplashScreen is also a good candidate for this. All your dialogs should be your splash screen children. At last, you can finish your splash screen by calling QSplashScreen::finish.
[Re-posting from duplicate-closed question since the top banner on it may cause people to skip that question entirely, and IMHO this one doesn't have a good answer.]
Here's a very simple example of showing a dialog before a QMainWindow. The dialog simply presents the option of starting the main app or not. They key points are that the QDialog portion happens before any other widgets are created (eg. QMainWindow here), and the app (main()) exits before that if needed. No reason to keep the QDialog around after it is used, so I create it on the stack and delete afterwards.
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
QDialog *d = new QDialog();
QPushButton *pbYes = new QPushButton("Would you like to play a game?", d);
QPushButton *pbNo = new QPushButton("Get me out of here!", d);
QObject::connect(pbYes, &QPushButton::clicked, [d]() { d->done(QDialog::Accepted); });
QObject::connect(pbNo, &QPushButton::clicked, [d]() { d->done(QDialog::Rejected); });
d->setLayout(new QVBoxLayout);
d->layout()->addWidget(pbYes);
d->layout()->addWidget(pbNo);
const int ret = d->exec();
delete d;
if (ret == QDialog::Rejected)
return 0;
QMainWindow mw;
mw.setCentralWidget(new QLabel("Welcome to the Game!", &mw));
mw.show();
return a.exec();
}
I'm making an application for Mac OS X in Qt, and wanted to spawn a thread that doesn't close on application close.
Is this possible? If so, how? I don't want the process to be stopped if a user force quits the application.
Thanks in advance.
Note: If this is not possible, is there any way I can make this happen? (Maybe with calling a command in bash?)
it's possible to achieve your goal by initiating a new process via QProcess::startDetached, as per documents http://doc.qt.io/qt-4.8/qprocess.html#startDetached
Starts the program program with the arguments arguments in a new process, and detaches from it. Returns true on success; otherwise returns false. If the calling process exits, the detached process will continue to live.
Unix: The started process will run in its own session and act like a daemon.
Edit:
Here is an example for MacOS
// run start script
QString scriptPath = "path-to-start-script/start.sh" ;
QString cmd = "open -a " + scriptPath;
QProcess::startDetached(cmd);
When you terminate a process, all threads within that process die - the process is the thread "container". If you want to spawn something that lives on beyond your current process, then spawn a new independant process.
If your user force-quits the application, that usually means that they want to control the energy or resource expenditure on their system. Thinking that you know better than the user would be rather in the user's face. Don't anger your users :)
All you really want is:
For the process to survive quitting it through normal means (pressing ⌘-Q, selecting Quit from the menu, closing the last window, etc.).
For the dock icon to disappear after the GUI has been quit, as is the normal and expected behavior.
For a cleanup code to run after the GUI has vanished.
To that effect, you only need to hide the dock icon/menubar and then perform the cleanup:
main.mm
// https://github.com/KubaO/stackoverflown/tree/master/questions/hidedock-39378276
#include <QtWidgets>
#include <AppKit/AppKit.h>
void hideDockIcon() {
[NSApp setActivationPolicy: NSApplicationActivationPolicyProhibited];
}
int main(int argc, char ** argv) {
QApplication app{argc, argv};
QLabel label{"Quit Me"};
label.setMinimumSize(200, 100);
label.show();
int rc = app.exec();
hideDockIcon();
qDebug() << "cleaning up";
QThread::sleep(5);
qDebug() << "cleanup finished";
return rc;
}
hidedock-39378276.pro
QT = widgets
CONFIG += c++11
TARGET = hidedock-39378276
TEMPLATE = app
OBJECTIVE_SOURCES += main.mm
LIBS += -framework AppKit
If u mean closing of Gui window by "Application Close" then it can be done easily...
#include "MainWindow.h"
#include <QApplication>
//////////////////////////////////////
#include <thread>
struct blabla {
std::thread th;
blabla():th([]{
// body of your thread
}) {}
~blabla(){
if(th.joinable())
th.join();
}
} singleton_obj;
/////////////////////////////////////
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec();
}
Now the applicaton window will quit but the daemon thread will run n background...
Enjoy
I have made an application to run only single instance using shared memory in qt.My code looks like this
int main(int argc, char *argv[])
{
QSharedMemory sharedMemory;
sharedMemory.setKey("4da7b8a28a378e7fa9004e7a95cf257f");
if(!sharedMemory.create(1))
{
return 1; // Exit already a process running
}
QApplication a(argc, argv);
Encoder *encoder = Encoder::instance();
encoder->show();
return a.exec();
}
Now, I need to show the already running instance to the user (Maximize the window), when they try to run another instance. How can I achieve this?
There is an easy setup using QtSingleApplication instead :
QtSingleApplication app("myapp",argc, argv);
if (app.isRunning()) {
QListIterator<QString> it(messagestosend);
QString rep("Another instance is running, so I will exit.");
bool sentok = false;
while(it.hasNext()){
sentok = app.sendMessage(it.next(),1000);
if(!sentok)
break;
}
rep += sentok ? " Message sent ok." : " Message sending failed; the other instance may be frozen.";
return 0;
}
To receive this message you should listen with your desired slot to the signal
void QtSingleApplication::messageReceived(const QString&)
My program has two modes GUI(on qml) and no GUI(command line).What code I must write for changing mode by passing argument in cmd
for example if I pass nameofapp.exe -no-gui must be work no-gui version
for simple qt/c++ application we have this code
QCoreApplication* createApplication(int &argc, char *argv[])
{
for (int i = 1; i < argc; ++i)
if (!qstrcmp(argv[i], "-no-gui"))
return new QCoreApplication(argc, argv);
return new QApplication(argc, argv);
}
int main(int argc, char* argv[])
{
QScopedPointer<QCoreApplication> app(createApplication(argc, argv));
if (qobject_cast<QApplication *>(app.data())) {
// start GUI version...
} else {
// start non-GUI version...
}
return app->exec();
}
It's from documentation,I want such of this for qml
OS is windows 7 ultimate but I don't think that it's depends on OS
You need at least one top level QObject per application type which will "make things happen" in the main event loop.
Assuming that you have made a clear separation of concern between the view and the backend (eg MVC), you will have 3 classes (which are QObject) :
MyAppBackend which does the actual work
MyGUIMainWindow which manage GUI input\outpout.
MyCLIMainObject which manage command line input\outpout
Each one should have a method to start doing work. For instance just showing a widget is how simple Qt apps start.
int main()
{
QApplication app;
MyGUIMainWindow window;
window.show();
return app.exec();
}
window.show() will queue an event which will be processed when app.exec(). is executed.
You need to do the same with a function which either post an event or emit a signal.
int main(int argc, char* argv[])
{
QScopedPointer<QCoreApplication> app(createApplication(argc, argv));
MyAppBackend backend;
backend.startDeffered();
if (qobject_cast<QApplication *>(app.data())) {
// start GUI version...
MyGUIMainWindow* window = new MyGUIMainWindow(0,...);
window->show();
} else {
// start non-GUI version...
MyCLIMainObject* cliobj = new MyCLIMainObject(0,...);
cliobj->showCLi();
}
return app->exec();
}
I've created a server using Qt and QTcpServer. It runs in the background and doesn't show any windows, but it uses an event loop.
My main.cpp looks like this:
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MyServer theServer;
return a.exec();
}
How do I notify my server to close, without resorting to TerminateProcess()? I'm fine with a Windows-only solution, so I can use WINAPI functions if needed.
Depending upon what the server is for, as you're using TCPServer, you could send it a message to tell it to quit, though you may want to authenticate who is sending that message.
Alternatively, have a controller application on the same machine that can talk to the server via a named pipe, which you can use to tell it to quit.
I just implemented it using QLocalServer. It turned out to be very easy:
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
static const char *quitSignalName = "My Service Quit Signal";
const QStringList &args = a.arguments();
if (args.size() == 2 && args[1] == "--shutdown") {
// Connect to the named pipe to notify the service it needs
// to quit. The QLocalServer will then end the event loop.
QLocalSocket quitSignal;
quitSignal.connectToServer(quitSignalName);
quitSignal.waitForConnected();
return 0;
}
// Listen for a quit signal, we connect the newConnection() signal
// directly to QApplication::quit().
QLocalServer quitSignalWatcher;
QObject::connect(&quitSignalWatcher, SIGNAL(newConnection()), &a, SLOT(quit()));
quitSignalWatcher.listen(quitSignalName);
MyServer theServer;
Q_UNUSED(theServer);
return a.exec();
}