In my project, I have made a GUI program that will occasionally send commands to a cli program. I do it like this:
system("folder\\program.exe -d folder\\inputFile.dat folder\\outputPath");
Obviously without those names but you get the idea. This works fine, except when my GUI program sends these commands, a command prompt window opens and does whatever the cli program is supposed to do. It looks very bad and unclean.
Is there any way I could "hide" the cli program window but still have it silently do what it needs to do?
Thanks for your time :)
EDIT: I tried olive's technique which was to use QDesktopServices and QUrl to call the program:
QDesktopServices::openUrl(QUrl("folder\\program.exe -d folder\\inputFile.dat folder\\outputPath"));
The console window isn't showing up, however, the program wasn't called at all. Are there any changes that need to be made to the path when using olive's technique rather than my original system() command?
I cannot determine whether you need a cross platform solution or not. On windows execution using start generally hides the command window.
system("start program.exe -d inputFile.dat outputPath");
I solved this problem like so:
QProcess::execute("start program.exe -d inputFile.dat outputPath");
The problem is, I can only do this once. Everytime I try to call it again, it will not work. The thing that makes this hidden is "start." Taking it out allows the console to be seen, it's just blank.
It seems like I need a way to "end" the program or whatever before running it again. (I say or whatever because I have no clue what/why adding "start" to the path does)
QDesktopServices::openUrl() is usually used if you wish to open a document (eg PDF document, web page) in a viewing or editing program and you're not sure which programs have been installed. This function lets the operating system choose for you from the list of default programs with respect to the file types.
Although you can also use the function to open executable files (eg console programs), an alternative to that would be using QProcess. If you don't need to communicate with the console program or wait for it to complete, you can just launch it in a fire-and-forget fashion using one of the two QProcess::startDetached() static functions
QProcess::startDetached
Sorry for misleading with QDesktopService::URL, later i understood that it wont accept parameter.
So implemented by improving error handling, if process not started/exited badly or waitfor the process to finish the task..I think this is useful
In QProcess, execute is blocking thread, but start is resuming the thread.
Current code is using start() API, but more or less featurewise like execute..
Code is copied from SO and modified little for the current requirements.
> Mainwindow.cpp
#include "mainwindow.h"
#include "ui_mainwindow.h"
#include <QProcess>
#include <QShortcut>
#include <QDebug>
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
cameraControl = new QProcess(this);
}
MainWindow::~MainWindow()
{
delete ui;
cameraControl->close();
delete cameraControl;
}
void MainWindow::on_pushButton_clicked()
{
// connect the camera control finished signal to the slot that will read the exit code and
// place the std output string from the process into a label on the form
connect(cameraControl, SIGNAL(finished(int , QProcess::ExitStatus )),
this, SLOT(on_cameraControlExit(int , QProcess::ExitStatus )));
// Disable the ui button do we don't get double presses
ui->pushButton->setDisabled(true);
// setup the gphoto2 arguments list
QStringList args;
args.append("d:\\text.txt");
// start the camera control
cameraControl->start("notepad",args);
// // wait for the process to finish or 30 seconds whichever comes first
cameraControl->waitForFinished(30000);
}
void MainWindow::on_cameraControlExit(int exitCode, QProcess::ExitStatus exitStatus)
{
qDebug() << cameraControl->errorString();
qDebug() << cameraControl->readAllStandardError();
qDebug() << cameraControl->readAllStandardOutput();
ui->pushButton->setEnabled(true);
}
MainWindow.h
#ifndef MAINWINDOW_H
#define MAINWINDOW_H
#include <QMainWindow>
#include <QString>
#include <QProcess>
#include <QObject>
namespace Ui {
class MainWindow;
}
class MainWindow : public QMainWindow
{
Q_OBJECT
public:
explicit MainWindow(QWidget *parent = 0);
~MainWindow();
void reply2();
private slots:
void on_pushButton_clicked();
void on_cameraControlExit(int exitCode, QProcess::ExitStatus exitStatus);
private:
Ui::MainWindow *ui;
QProcess* cameraControl;
};
#endif // MAINWINDOW_H
#include "mainwindow.h"
#include <QApplication>
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec();
}
in your Qt program,there is a .pro file.You can add this line into the file:
config+=console
Related
I use synchronously block QThread::sleep() function to do timing, which shows number one after another by the time.
the expected running process is synchronously block current thread 2 seconds, and run the following code to change displayed number, and synchronously block another 2 seconds, and so on..., the thought works well in non GUI program.
but in GUI mode, the label only show 9, which is the last number to be displayed.
what leads to the different outcome of the synchronous blocking function sleep in GUI and non GUI program?
#include <windows.h>
#include "widget.h"
#include "ui_widget.h"
#include <QDebug>
#include <QThread>
Widget::Widget(QWidget *parent) :
QWidget(parent),
ui(new Ui::Widget)
{
ui->setupUi(this);
}
Widget::~Widget()
{
delete ui;
}
//slot of start timing button
void Widget::on_pushButton_2_clicked()
{
for(int i=0;i<10;i++){
QThread.sleep(2);
ui->label->setText(QString::number(i));
}
}
The GUI needs to continually verify events such as the mouse, the keyboard, etc. and perform actions if certain conditions are met, that is called eventloop. In the case of sleep() it is a blocking task that does not allow the eventloop to run, generating the GUI to freeze (if you want to verify it, try to change the size of the window), so inside the GUI thread you should avoid to use that kind of functions, the blocking tasks you have to turn them into asynchronous or execute it in another thread.
But the task of the sleep() can be replaced by a QTimer without blocking the GUI:
*.h
#ifndef WIDGET_H
#define WIDGET_H
#include <QTimer>
#include <QWidget>
namespace Ui {
class Widget;
}
class Widget : public QWidget
{
Q_OBJECT
public:
explicit Widget(QWidget *parent = 0);
~Widget();
private slots:
void on_pushButton_2_clicked();
void onTimeout();
private:
Ui::Widget *ui;
int counter;
QTimer timer;
};
#endif // WIDGET_H
*.cpp
#include "widget.h"
#include "ui_widget.h"
#include <QLabel>
Widget::Widget(QWidget *parent) :
QWidget(parent),
ui(new Ui::Widget)
{
ui->setupUi(this);
counter = 0;
connect(&timer, &QTimer::timeout, this, &Widget::onTimeout);
}
Widget::~Widget()
{
delete ui;
}
void Widget::on_pushButton_2_clicked()
{
timer.start(2000);
}
void Widget::onTimeout()
{
ui->label->setText(QString::number(counter));
counter++;
if(counter > 10){
counter = 0;
timer.stop();
}
}
Another option is to use QEventLoop with QTimer:
void Widget::on_pushButton_2_clicked()
{
for(int i=0;i<10;i++){
QEventLoop loop;
QTimer::singleShot(2000, &loop, &QEventLoop::quit);
loop.exec();
ui->label->setText(QString::number(i));
}
}
Update:
what leads to the different outcome of the synchronous blocking function sleep in GUI and non GUI program?
If you are creating a non GUI application using Qt you will also have problems, although the effect may be less visible.
In the case of the GUI as I said there is an eventloop that handles events, and among them that of repainting, I mean when you set the new text in the QLabel, this is not painted automatically but Qt decides the right moment. That's why when you use QThread::sleep() you do not have time to update the painting.
Obviously in a non GUI application, the eventloop does not verify many events as the one painted by it does not see the effect, in fact in a script that only prints numbers it does not verify any event.
To notice the problem, let's use the following example:
#include <QCoreApplication>
#include <QThread>
#include <QTimer>
#include <QDebug>
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
QTimer timer;
QObject::connect(&timer, &QTimer::timeout, [](){
qDebug()<< "hello world";
});
timer.start(1000);
qDebug()<< "start blocking";
QThread::sleep(10);
qDebug()<< "end blocking";
return a.exec();
}
We will see that nothing is printed until the sleep() ends, that is, blocking the eventloop that allows the QTimer to do its work.
Answering your comment:
but what still makes me puzzled is why after finishing executing sleep function, after stopping blocking current thread, the following codes can't run as normal
ui->label->setText(QString::number(i)); this statement, right after sleep function
Asynchronous tasks such as painting have less priority than synchronous tasks, that is to say first Qt will execute the for loop and then just do the asynchronous tasks, so in the for the variable that stores the QLabel text is updated, that is to say 0, 1 , ..., 9, and after that, the task is handed over to the eventloop so that it just paints the last value, that is, the 9.
Note:
You can force the evenloop to update within synchronous execution with QXXXApplication::processEvents(), but this is often considered a bad practice, I only show it so you know it but avoid using it:
for(int i=0;i<10;i++){
QThread.sleep(2);
ui->label->setText(QString::number(i));
QApplication::processEvents();
}
Getting right to it I have a MainWindow and a dialog window which is executed if a condition is met but the problem is I can't get the app to quit if the cancel button from the dialog window is clicked. I've tried putting qApp->quit() in the slot function for the cancel button. I've tried connecting the cancel button slot to the predefined close slot for the MainWindow object via a clickme() signal from the dialog class. (as shown below)
qt application does not quit I read the answer to this question which I think got me close because it made me realize that I can't quit the app before showing the MainWindow but making that change didn't solve the problem. I even tried to explicitly emit the clickme() signal from cancel button slot but that actually caused the OS to throw a signal which threw an error at me saying "the inferior stopped because it received a signal from the operating system signal name: SIGSEGV
signal meaning: segmentation fault"
Here's my code:
Notice warning; // this is the object for the dialog window also all of this code is in main.cpp
warning.setModal(true);
QObject::connect(&warning, SIGNAL(clickme()), &warning, SLOT(on_Cancel_button_clicked()));
QObject::connect(&warning, SIGNAL(clickme()), &w, SLOT(close()));
warning.exec();
Also before that code is
MainWindow w;
w.show();
Also while writing this question I tried this
QObject::connect(&warning, SIGNAL(clickme()), qApp, SLOT(quit()));
But that still didn't work. If you need more info just let me know.
Update: I'm starting to think that the reason I'm having so much trouble with this connect signal/slot function is because it's not designed to connect two windows of two different classes and I should rework my app to do everything from the MainWindow class which is a shame because when I picture a GUI program I picture multiple windows connected to each other regardless of whether or not the object representing each window is from the same class as the others yet I have such a hard time trying do that with the QT framework when it comes to trying to connect objects of different classes.
Update: please forgive me. I assume that the code that I originally thought was the answer would work and took a break from working on the program before actually testing out that code. Going back to it now I discovered that it doesn't work. The code I'm referring to is the following
QMessageBox msg;
msg.setText("Continue?");
msg.addButton(QMessageBox::Yes);
msg.addButton(QMessageBox::No);
QObject::connect(&msg, &QMessageBox::rejected,
&app, &QApplication::quit); // this line doesn't work for me and I don't know why
QObject::connect(&msg, &QMessageBox::accepted, [&dlg]{
(new QLabel("I'm running")).show();
});
QApp->quit(); should work. Remove warning.setModal(true); The dialog becomes modal when you call exec(). SetModal(true) should be used with show() according to Qt docs. So this may be causing your problem.
I think I've found the problem.
Probably, you're calling exec() twice:
To enter the QApplicationevent loop
To execute the dialog.
Use show() instead of exec() for the dialog. You have an example below where you can check the signal/slot works well. In your application, you need the slot to close the window, but:
With the line of code dialog.exec();, the app keeps running. This is your issue.
With the line of code dialog.show();, the app stops.
By the way, I saw your last question update, but it is not correct. In fact, of course you can connect two different classes.
window.h
#ifndef WINDOW_H
#define WINDOW_H
#include <QApplication>
#include <QMainWindow>
#include <QAbstractButton>
#include <QDebug>
#include "dialog.h"
class Window : public QMainWindow
{
Q_OBJECT
public:
Window()
{
dialog = new Dialog();
dialog->setText("Continue?");
dialog->addButton(QMessageBox::Yes);
dialog->addButton(QMessageBox::No);
auto onClick = [this]() {
auto role = dialog->buttonRole(dialog->clickedButton());
if (role == QMessageBox::NoRole) {
qDebug() << "QMessageBox::NoRole";
QApplication::quit();
}
if (role == QMessageBox::YesRole) {
qDebug() << "QMessageBox::YesRole";
}
};
QObject::connect(dialog, &QMessageBox::buttonClicked, onClick);
dialog->show(); // this must be show(), not exec()
}
virtual ~Window() { delete dialog; }
private:
Dialog *dialog;
public slots:
void windowSlot() { qDebug() << Q_FUNC_INFO;
close();
}
};
#endif // WINDOW_H
dialog.h
#ifndef DIALOG_H
#define DIALOG_H
#include <QMessageBox>
class Dialog : public QMessageBox
{
Q_OBJECT
public:
Dialog() {}
virtual ~Dialog() {}
};
#endif // DIALOG_H
main.cpp
#include <QApplication>
#include <QtGui>
#include "window.h"
int main(int argc, char **argv)
{
QApplication app(argc, argv);
Window window;
window.setWindowTitle("window");
window.show();
return app.exec();
}
Update #1: a very interesting post.
Hi i have made a gui in qt4 designer and want to add custom slots with custom class.
It project compiles nicely without errors but my custom function wont work what am i doing wrong? I will show u the header file qt4 designer made for me and ill show u my custom file as well as the main.cpp.. first the main.cpp
I have revised my code, here is what i have now i have added a file called sweetest.cpp and edited the sweetest.h here are my new file and the error i recieve..
First main.cpp
#include "ui_sweetguiform.h"
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QWidget *widget = new QWidget;
Ui::SweetGuiForm ui;
ui.setupUi(widget);
widget->show();
return app.exec();
}
now my custom header file sweetest.cpp
#include "sweetest.h"
// trying to include the .moc file wouldnt work at all.
now the sweettest.h file with my code
#include "ui_sweetguiform.h"
class SweetGuiForm : public QWidget
{
Q_OBJECT
public:
SweetGuiForm( ): ui( new Ui::SweetGuiForm )
{
ui->setupUi( this );
connect(ui->buttonBox, SIGNAL(accepted()), this, SLOT(on_buttonBox_accepted()));
}
public slots:
void on_buttonBox_accepted()
{
ui.textEdit->setText(QString::number(23));
}
protected:
Ui::SweetGuiForm* ui;
};
Here is the compile error i recieve.. I am really stuck
In file included from sweetest.cpp:1:
sweetest.h: In member function ‘void SweetGuiForm::on_buttonBox_accepted()’:
sweetest.h:16: error: request for member ‘textEdit’ in ‘((SweetGuiForm*)this)->SweetGuiForm::ui’, which is of non-class type ‘Ui::SweetGuiForm*’
make: *** [sweetest.o] Error 1
I think im getting closer
The way that signals and slots work is that you must connect a signal to a slot. In your code, the simplest way to do that is in the constructor for the SweetGuiForm. You need to add:
SweetGuiForm() : ui(new Ui::SweetGuiForm) {
ui->setupUi(this);
connect(ui->buttonBox, SIGNAL(accepted()), this, SLOT(on_buttonBox_accepted()));
}
When the buttonBox emits its accepted signal all slots connected to it will be called.
update 1
On further inspection of your code, you are also missing the Qt macros that are used by the Qt MOC (meta-object compiler) system (http://qt-project.org/doc/qt-4.8/moc.html):
class SweetGuiForm : public QWidget
{
Q_OBJECT
public:
...
};
You also have to push the code through the MOC tool. It will generate a source file that needs to be included in your source. As I recall, you must include that in a cpp file; inclusion in a header is problematic. The following should be sufficient:
sweetguiform.cpp:
#include "suiteguiform.h"
#include "sweetguiform.moc"
update 2
On further further reflection, I had forgotten about the automatic signal/slot connection feature when you name your slots using special names (such as on_buttonBox_accepted). There is a blog post on just that here: http://qtway.blogspot.com/2010/08/automatic-connections-using-qt-signals.html. I've not used it myself, so I can't comment on its ability to work when using a ui member variable, though I suspect that it does not work in that arrangement. Regardless, you still need the Q_OBJECT macro and MOC.
Ok guys i figured it out and thought ide share what i found.
First the documentation is excellent in qt4 use it.
I found you can use qt4 designer to generate the hearder files, first i complied it with out custom slots and generated the ui_sweetgui2.h, then i could open the sweetgui2.h file generated by the first compile i did delete what qt4 put in there and put my custom slots in at that stage. did my head in for hours.... days.
so here is the simplest app on earth but its got me started so here are the files and code that worked for me and the documentation basically got me to click on to whats going on.
main.cpp
Strait from the documentation just changed the class name "SweetGuiForm".
#include <QApplication>
#include "sweetgui2.h"
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
SweetGuiForm sweetgui;
sweetgui.show();
return app.exec();
}
next sweetgui2.cpp
My first attempt at c++.. ugly but works. But again i found everything about getting the text from the textEdit and type casting it to a int in the calculator example and searching for toPlainText() in the qt4 assistant. notice below im including the file that i will define the new slots that ill show further on in my explanation. hope im making sense.
#include <QtGui>
#include "sweetgui2.h"
SweetGuiForm::SweetGuiForm(QWidget *parent)
: QWidget(parent)
{
ui.setupUi(this);
}
void SweetGuiForm::on_buttonBox_accepted()
{
QString stringamount = ui.textEdit->toPlainText();
int digitamount = stringamount.toInt();
ui.textEdit->setText(QString::number(25 + digitamount));
}
next sweetgui2.h the one we included above My custom header file with my custom slot.... simple as i said from the calculator example and twisted a lil.. you will get it this is not what it looks like when you generate it from designer on the first compile this is after i have deleted nearly all what was there and opened the calculator example and followed in the tutorial wich shows you how to make your first custom slot .
#ifndef SWEETGUI2_H
#define SWEETGUI2_H
#include "ui_sweetgui2.h"
class SweetGuiForm : public QWidget
{
Q_OBJECT
public:
SweetGuiForm(QWidget *parent = 0);
private slots:
void on_buttonBox_accepted();
private:
Ui::SweetGuiForm ui;
};
#endif // SWEETGUI2_H
Again Straight from the documentation. I used the calculator example to get the basic flow.
next ui_sweetgui2.h
I include this file because i was trying to add my slots to the sweetgui2.h that was generated by qt4 desinger. doesnt work guys ..so i compiled first with sweetgui2.h file you generate with the designer, i go to forms menu then view code that is where u can save header files. then of course save the ui file.
and compile then you end up with the ui_sweetgui2.h file wich looked like the sweetgui2.h generated by the designer
#ifndef UI_SWEETGUI2_H
#define UI_SWEETGUI2_H
#include <QtCore/QVariant>
#include <QtGui/QAction>
#include <QtGui/QApplication>
#include <QtGui/QButtonGroup>
#include <QtGui/QDialogButtonBox>
#include <QtGui/QHeaderView>
#include <QtGui/QTextEdit>
#include <QtGui/QWidget>
QT_BEGIN_NAMESPACE
class Ui_SweetGuiForm
{
public:
QDialogButtonBox *buttonBox;
QTextEdit *textEdit;
void setupUi(QWidget *SweetGuiForm)
{
if (SweetGuiForm->objectName().isEmpty())
SweetGuiForm->setObjectName(QString::fromUtf8("SweetGuiForm"));
SweetGuiForm->resize(486, 238);
buttonBox = new QDialogButtonBox(SweetGuiForm);
buttonBox->setObjectName(QString::fromUtf8("buttonBox"));
buttonBox->setGeometry(QRect(150, 200, 181, 26));
buttonBox->setStandardButtons(QDialogButtonBox::Cancel|QDialogButtonBox::Ok);
textEdit = new QTextEdit(SweetGuiForm);
textEdit->setObjectName(QString::fromUtf8("textEdit"));
textEdit->setGeometry(QRect(150, 50, 221, 91));
retranslateUi(SweetGuiForm);
QObject::connect(buttonBox, SIGNAL(rejected()), SweetGuiForm, SLOT(close()));
QMetaObject::connectSlotsByName(SweetGuiForm);
} // setupUi
void retranslateUi(QWidget *SweetGuiForm)
{
SweetGuiForm->setWindowTitle(QApplication::translate("SweetGuiForm", "SweetGuiBack", 0, QApplication::UnicodeUTF8));
} // retranslateUi
};
namespace Ui {
class SweetGuiForm: public Ui_SweetGuiForm {};
} // namespace Ui
QT_END_NAMESPACE
#endif // UI_SWEETGUI2_H
Then i recompiled again with my custom slots and shazam! now i can begin to learn some c++.
thanks for all the hints guys, between you all and the documentation i got there.
hope this helps. The main thing to look at is the order things are included i mean my sweetgui2.cpp file
includes the sweetgui2.h file. wich grabs all my custom stuff.
My sweetgui2.h file
includes the ui_sweetgui2.h wich has all the stuff the designer made when i did the first compile. Main.cpp calls my SweetGuiForm class .
As you all can see my first couple days with c++ but this is a good starting point. it made me put the basic flow together in my mind. qt4 assistant look at it.. its well explained and the examples seem very good. ho ho ho merry xmas. hope my explanation helps.
What I'm trying to do is launch a program within another program using QProcess and then save the output from the launched program into a QTextEdit of the launcher program. Every time I launch this program I want it to add more text to the QTextEdit. Now I get the program to launch but then after the text is supposed to be written it crashes. Here is the code:
#include <QWidget>
#include <QPushButton>
#include <QTextEdit>
#include <QProcess>
#include <QVBoxLayout>
#include <QApplication>
class Widget : public QWidget
{
Q_OBJECT
QTextEdit* text;
public:
Widget() : text(new QTextEdit) {
QPushButton* addBtn = new QPushButton("Add Module");
text->setReadOnly(true);
QVBoxLayout* layout = new QVBoxLayout(this);
layout->addWidget(addBtn,0);
layout->addWidget(text);
connect(addBtn,SIGNAL(clicked()),SLOT(launchModule()));
}
Q_SLOT void launchModule() {
QString program = "C:/A2Q2-build-desktop/debug/A2Q1.exe";
QProcess *myProcess = new QProcess(this);
connect(myProcess, SIGNAL(finished(int)), SLOT(finished()));
connect(myProcess, SIGNAL(error(QProcess::ProcessError)), SLOT(finished()));
myProcess->start(program);
}
Q_SLOT void finished() {
QProcess *process = qobject_cast<QProcess*>(sender());
QString out = process->readAllStandardOutput(); // will be empty if the process failed to start
text->append(out);
delete process;
}
};
int main(int argc, char **argv)
{
QApplication app(argc, argv);
Widget w;
w.show();
app.exec();
}
#include "main.moc"
It's crashing because you're deleting the sender object while inside a slot. Instead of delete process, you should
process->deleteLater();
For logging purposes you should be using QPlainTextEdit instead of a QTextEdit. The former is faster. You're prematurely pessimizing by using the latter. Alas, even QPlainTextEdit becomes abysmally slow if you're sending about 100 lines/s (at least on Qt 4.8). If you want a really fast log view, you'll need to use QListWidget, with a caveat, or roll your own.
I have a complete example of how to send to and receive from a process in another answer.
The process is crashing because you're deleting the parent from within the finished slot.
Also, it's probably easier to do something like this:
QObject::connect(process, SIGNAL(readyReadStandardOutput()), this, SLOT(getOutput()));
instead of using the finished() slot. But that's more personal preference than anything.
I was trying the QFileSystemWatcher out and it somehow doesn't work as expected. Or am I doing something wrong?
I've set the QFileSystemWatcher to watch a single file. When I modify the file for the first time, fileChanged() gets emited, that's OK. But when I modify the file again, fileChanged() doesn't get emited anymore.
Here is the source code:
main.cpp
#include <QApplication>
#include "mainwindow.h"
int main(int argc, char **argv)
{
QApplication app(argc, argv);
MainWindow window;
window.show();
return app.exec();
}
mainwindow.h
#include <QDebug>
#include <QFileSystemWatcher>
#include <QMainWindow>
#include <QString>
class MainWindow : public QMainWindow
{
Q_OBJECT
public:
MainWindow();
private slots:
void directoryChanged(const QString & path);
void fileChanged(const QString & path);
private:
QFileSystemWatcher * watcher;
};
mainwindow.cpp
#include "mainwindow.h"
MainWindow::MainWindow()
{
watcher = new QFileSystemWatcher(this);
connect(watcher, SIGNAL(fileChanged(const QString &)), this, SLOT(fileChanged(const QString &)));
connect(watcher, SIGNAL(directoryChanged(const QString &)), this, SLOT(directoryChanged(const QString &)));
watcher->addPath("path to directory");
watcher->addPath("path to file");
}
void MainWindow::directoryChanged(const QString & path)
{
qDebug() << path;
}
void MainWindow::fileChanged(const QString & path)
{
qDebug() << path;
}
Thank you for your answers.
Edit 1
I ran this code under Linux.
Edit 2
I actually need to check all MetaPost files in a tree given by some directory, whether they were modified. I will probably stick to my alternative solution, which is to run QTimer every second and manually check all files. The QFileSystemWatcher probably does this in similar fashion internally, but probably more effectively.
Had the same problem just now. Seems like QFileSystemWatcher thinks that the file is deleted even if it's only modified. Well at least on Linux file system. My simple solution was:
if (QFile::exists(path)) {
watcher->addPath(path);
}
Add the above to your handler of fileChanged(). Change the word watcher as necessary.
I had the same problem using Qt5 on Linux. Found out the reason :
Some text editors, like kate, don't modify the contents of a file, but replace the original file with a new file. Replacing a file will delete the old one (IN_DELETE_SELF event), so qt will stop watching the file.
A solution is to also watch the file's directory for creation events.
I can confirm your problem with current Qt5 and Linux.
In addition to the answer given by Peter I solved this problem by adding the following code to the end of the slot-function:
QFileInfo checkFile(path);
while(!checkFile.exists())
std::this_thread::sleep_for(std::chrono::milliseconds(10));
watcher->addPath(path);
Note that if you add the path immediately, the file often does not exist yet, you get a warning and nothing will be added at all and the watcher looses this path. Therefore, you have to wait/sleep until the file is back to life again, then add it.
Also note that in this example I used C++11 and included and for realizing the sleep.