Creating connection with dialog from thread
-
Hello.
I have Dialog inheriting from QMainWindow. (class Dialog : public QMainWindow) . There is slot in this dialog:
@public slots:
void StdOut(const QString &str);@
In other place I have QThread class with run method and I want to connect (and disconnect on exit) one signal:
@void thShell::run()
{
QObject::connect(this, SIGNAL(StdOut(const QString&)), &Ui::Dialog, SLOT(StdOut(const QString&)));
/* do sth */
QObject::disconnect(this, SIGNAL(StdOut(const QString&)), &Ui::Dialog, SLOT(StdOut(const QString&)));
}@But I dont know how to reference to Dialog class which is in Ui namespace and his slot. I have error:
bq. expected primary-expression before ',' tokenAny sugestions?
-
You should connect in your Dialog class, and use Qt:QueuedConnection if possible.
-
-
You could make Dialog into a Singleton, and then it would work. But it's a dangerous path.
-
If I am right, The Ui::Dialog your given in code is a common C++ class generated by uic, so it doesn't have signals or slots.
-
No no, Dialog is Qt class:
@namespace Ui {
class Dialog;
}class Dialog : public QMainWindow
{
Q_OBJECT
...
}@Automatically generated by uic is Ui_Dialog class which is really standard C++ class:
@namespace Ui {
class Dialog: public Ui_Dialog {};
} // namespace Ui
@Sierdzio, can you explain this method with Singleton and why it is dangerous?
Best regards guys
-
Singleton is a class that can be instantiated only once. So it allows you to include it's header wherever you need it, and use it's public methods (if you are careful you can even do it across threads). This makes it very convenient, easy to use, and very fast to implement.
In my opinion (and this is personal & biased, you have been warned) this - in the long term - leads to much sloppiness in code. Instead of creating separate, well defined and interchangeable classes, you (and those who will come afterwards to maintain your code) will start relying on the Singleton more and more. Then one day it will turn out your code is so dependent on this (or these) singletons that you can not easily modify your code without affecting the global state (debugging nightmare) and you can't move some objects to a thread, because suddenly you would need to rewrite them and guard against thread problems.
Implementing it all with signals and slots is more cumbersome, but if you stick to it you will get a set of classes that are largely independent from one another: if you need to change something later, you simply unplug the connections and change the stuff. If you need to move to a thread: no problems, just make the connections queued. And perhaps most importantly, by designing your code in a more functional way you can avoid being stateful, which helps in debugging, and prevents some errors from happening.
As said, though, this is my own opinion and you may easily find people who disagree.
-
Yes, Dialog is a subclass of QObject. But Ui::Dialog is a pure C++ class which doesn't have any SIGNALS and SLOTS.
[quote author="nibbit" date="1375861314"]No no, Dialog is Qt class:
@namespace Ui {
class Dialog;
}class Dialog : public QMainWindow
{
Q_OBJECT
...
}@Automatically generated by uic is Ui_Dialog class which is really standard C++ class:
@namespace Ui {
class Dialog: public Ui_Dialog {};
} // namespace Ui
@
[/quote]
