Qt - Q_PROPERTY's NOTIFY signal not emited about MEMBER change - c++

I have a private class member variable status and i want to emit a signal with its value everytime it changes. Therefore I use Q_PROPERTY and specify a signal with NOTIFY:
#ifndef CAMERACONTROL_H
#define CAMERACONTROL_H
#include <QObject>
#include <iostream>
class CameraControl : public QObject
{
Q_OBJECT
Q_PROPERTY(QString status MEMBER status NOTIFY statusChanged)
private:
QString status;
public:
explicit CameraControl(QObject *parent = nullptr);
~CameraControl();
void changeStatus()
{
std::cout << "changeStatus called" << std::endl; // The function definitely gets called!
this->status = "Change status again!";
}
public slots:
void outputStatus(const QString &status) {
std::cout << status.toStdString() << std::endl;
}
signals:
void statusChanged(const QString &status);
};
#endif // CAMERACONTROL_H
I connect the statusChanged signal with the outputStatus slot inside the constructor:
#include "CameraControl.h"
CameraControl::CameraControl(QObject *parent) :
QObject(parent)
{
this->cameraHandle = nullptr;
this->connect(this, &CameraControl::statusChanged, this, &CameraControl::outputStatus);
this->status = "Change status text";
}
When running the application and change the status through another object i get no ouput and also no message from qt regarding this issue.
Please be aware that this is not the actual implementation. The status get changed through various member functions quite a lot without any output. However the connect call aswell as the statusChanged and the outputStatus are exactly implemented as in this question.
Because the Q_PROPERTY has the same name then the member i thought about this being an issue and changed the Q_PROPERTY to the following without any difference:
Q_PROPERTY(QString qstatus MEMBER status NOTIFY statusChanged)
Does anyone has a clue where the problem lies?

NOTIFY tells Qt that you will emit the statusChanged signal when you change the property. It will also cause Qt to emit the signal if the property is modified but it will not emit the signal when you change the class member that backs the property. It doesn't cause the signal to be emitted when you change the value of the property.
You need to implement this yourself, e.g.:
void setStatus(QString value)
{
if (value != status)
{
status = value;
emit statusChanged;
}
}
Alternatively if you call setProperty this will cause the signal to be emitted automatically:
void setStatus(QString value)
{
setProperty("status", value);
}
Note this is likely to be slower than implementing the previous method as it involves wrapping value in a QVariant and then doing a lookup through the objects meta information.

Related

How can I emit a signal of another instance from _clicked() event?

the runnable project is here:
enter link description here
I sincerely glad to have your detail answers to solve this, but I am still confusing on this issue:
case 1: changing socket_session as a member variable of mainwindow
class MainWindow : public QMainWindow
{
Q_OBJECT
public:
explicit MainWindow(QWidget *parent = 0);
~MainWindow();
SocketThread* socket_session;
private:
...
But this is not the solution to access setFlag, even after I change the `Form1::on_qpushButton__set_white_level_0_clicked()' function like this:
void Form1::on_qpushButton__set_white_level_0_clicked() {
qDebug() <<"clicked()";
socket_session->setThreadFlag(true);
}
Still it doesn't make sense because form1 instance doesn't have "the" instance of socket_thread which has been instantiated from mainwindow.
There's a solution I think is making another class that includes all instances that I want to use from inside of mainwindow but I don't think that is a good one because I am using thread and accessing a global big instance class that includes all of them to be "shared" is not a good idea for someone like me.
#include <form1.h>
#include <ui_form1.h>
#include "socketthread.h"
Form1::Form1(QWidget *parent) :
QWidget(parent),
ui(new Ui::Form1) {
ui->setupUi(this);
}
Form1::~Form1() {
delete ui;
}
void Form1::on_qpushButton__set_white_level_0_clicked() {
qDebug() <<"clicked()";
socket_session->setThreadFlag(true);
}
enter image description here
I know I am lack of understanding about this but, do I wanna make something nobody does...? I think everyone wants to separate all objects and their methods clearly and communicate via signals or calling functions from delivered object instances...
case 2: ... let me try how you suggested make possible first...
I can read C++ code and overall structure, but I don't know why I have to struggle with this, so please help me, dear Guru.
On socketthread.h :
class SocketThread : public QThread {
Q_OBJECT
public:
QTcpSocket *socket_session;
SocketThread();
~SocketThread(){}
bool connectToServer(QString, int);
void sendData(const char*, int, int);
void run(void);
private:
QString message;
volatile bool threadFlag;
signals:
void changedThreadFlag(void);
void changedMessageStr(void);
void setThreadFlag(bool);
void setMessageStr(QString);
private slots:
void setStr(QString);
void setFlag(bool);
void socketError(QAbstractSocket::SocketError);
};
And its implementation is...
SocketThread::SocketThread() {
socket_session = NULL;
threadFlag = false;
message = "NULL";
connect(this, SIGNAL(setThreadFlag(bool)), this, SLOT(setFlag(bool)));
}
...
void SocketThread::setStr(QString str) {
message = str;
}
void SocketThread::setFlag(bool flag) {
threadFlag = flag;
}
void SocketThread::run() {
while(true) {
if(threadFlag) {
QThread::msleep(100);
qDebug() << message;
} else
break;
}
qDebug() << "loop ended";
}
And I have one form which has a button, and I put a clicked() slot of it like this...
void Form1::on_qpushButton__set_white_level_0_clicked() {
qDebug() <<"clicked()";
--how can I emit the signal of the one of socketthread from here??
}
Now, the mainwindow is like this:
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow) {
QString addr_server = "223.194.32.106";
int port = 11000;
SocketThread* socket_session = new SocketThread();
socket_session->connectToServer(addr_server, port);
ui->setupUi(this);
Form1* form1;
form1 = new Form1();
ui->stackedWidget_mainwindow->addWidget(form1);
ui->stackedWidget_mainwindow->setCurrentWidget(form1);
socket_session->run();
...
I just simply want to emit the signal setThreadFlag of the socketthread from inside of QPushbutton_clicked() slot.
Once the socket_session->run() started, I need to change the threadFlag by clicking the button by emitting setThreadFlag() of one's from the running thread. And I just stuck in here.
Does it possible even?
Or am I doing this all wrong from the beginning?
As mentioned in this post:
"Emitting a signal" == "calling a function"
So all you really have to do is call the signal function, and all connected slots should be called.
This of course means that the Form1 object needs a pointer to the thread object, i.e. it needs a copy of socket_session. Then you can simply call the signal on the object
socket_session->setThreadFlag(your_flag);
Of course, if the Form1 have a copy of the socket_session pointer, it might as well call setFlag directly, if it was public.
I just simply want to emit the signal setThreadFlag of the socketthread from inside of QPushbutton_clicked() slot.
No signal is needed – just call the function.
void Form1::on_qpushButton__set_white_level_0_clicked() {
qDebug() <<"clicked()";
// --how can I emit the signal of the one of socketthread from here??
// E.g. this way:
socket_session->setThreadFlag(true);
}
To make this possible, another fix is needed:
socket_session is a local variable in OP's exposed code.
To make it "persistent", it has to become e.g. a member variable.
So, the constructor MainWindow::MainWindow() has to be changed:
// Nope: SocketThread* socket_session = new SocketThread();
// Instead:
socket_session = new SocketThread();
and SocketThread* socket_session; has to be added to member variables of class MainWindow.
To make it accessible in Form1, it has to be passed to Form1 as well.
This could be done e.g. by making it a member variable in Form1 also which is initialized with a constructor argument (or set from MainWindow afterwards).
(I must admit that I never have used the Qt UI builder QtDesigner but build all my UIs by C++ code exclusively.)
But, now, another fix is necessary:
volatile doesn't make a variable suitable for interthread communication.
(This was used in ancient times before multi-threading started to be supported by C++11.)
However, this is wrong: Is volatile useful with threads?
An appropriate fix would be to use std::atomic instead:
// Wrong for interthread-com.
//volatile bool threadFlag;
// Correct:
std::atomic<bool> threadFlag; // #include <atomic> needed
FYI: SO: Multithreading program stuck in optimized mode but runs normally in -O0
And, finally, in SocketThread::SocketThread():
connect(this, SIGNAL(setThreadFlag(bool)), this, SLOT(setFlag(bool)));
is not necessary in this case.
SocketThread::setThreadFlag() could call SocketThread::setFlag() directly, or even write threadFlag itself:
void setThreadFlag(bool flag) { threadFlag = flag; }
As I (recommended to) make threadFlag atomic, it can be accessed from any thread without causing a data race.
Update:
After OP has updated the question:
I just simply want to emit the signal setThreadFlag of the socketthread from inside of QPushbutton_clicked() slot.
The button (created from UI Form1) can be connected in the MainWindow as well (without using any method of Form1):
QObject::connect(form1->button1, &QPushButton::clicked,
socket_session, &SocketThread::setThreadFlag,
Qt::QueuedConnection);
Notes:
About form1->button1, I'm not quite sure.
I noticed that widgets in UI generated forms can be accessed this way but I don't know the exact details (as I never used the Qt UI builder on my own).
I used the Qt5 style of QObject::connect().
This is what I would recommend in any case.
The Qt5 style is verified at compile time. –
Wrong connections are detected by the C++ type checking.
Additionally, any function with matching signature can be used – no explicit exposure of slots is anymore necessary.
Even conversion of non-matching signature or adding additional parameters becomes possible by using C++ lambdas which are supported as well.
Qt: Differences between String-Based and Functor-Based Connections
It is possible to connect signals and slots of distinct threads.
I used Qt::QueuedConnection to remark this as interthread communication.
(However, I roughly remember that Qt might be able to detect it itself.
See the doc. for Qt::AutoConnection which is the default.
Further reading: Qt: Signals & Slots
Btw. using the Qt signals for inter-thread communication would exclude the necissity to make SocketThread::threadFlag() atomic. It could become a simple plain bool threadFlag; instead. The slot SocketThread::setThreadFlag() is called in the Qt event loop of QThread, in this case.

Qt Get Notified by a signal emitted by a class member

I am trying to reuse a library as a module in Qt, therefore, I want be make less modifications/patches to it as possible. The goal is to be notified by the Q_EMIT that is emitted by a class member. My example code is as follows:
myclass.cpp
public:
MyClass::MyClass(QObject* parent) : QObject(parent)
{
this->manager = new QOfonoManager(this);
}
public slots:
void MyClass::manager_available()
{
qDebug() << "Manager available";
QStringList modems = this->manager->modems();
qDebug() << "Modems:" << modems << "-" ;
}
public:
void MyClass::test()
{
QStringList modems = this->manager->modems(); //Starts getting available modems
connect (this->manager,SIGNAL(availableChanged()),this,SLOT(manager_available()));
}
qofonomanager.cpp
void QOfonoManager::onGetModemsFinished(QDBusPendingCallWatcher* watcher)
{
......
Q_EMIT availableChanged(true);
}
QOfonoManager::QOfonoManager(QObject *parent) :
QObject(parent),
d_ptr(new Private)
{
.....
}
When I call MyClass::test, I expect the member class to signal availableChanged to MyClass::available_changed. What am I missing here, can I make use of the Q_EMIT availableChanged(true) without having to modify QOfonoManager code.
Any help is greately appreciated.
I think the underlying issue is that your connect statement doesn't match the signal spec for QOfonoManager::availableChanged. The signal is emitted with a bool parameter...
Q_EMIT availableChanged(true);
But your connect statement states it to be a signal with no parameters...
connect(this->manager, SIGNAL(availableChanged()), this, SLOT(manager_available()));
(Do you not get an error message at the console? Something along the lines of "QObject::connect: No such signal ..." ?)
Changing the connect statement to the following should help to fix the problem...
connect(this->manager, SIGNAL(availableChanged(bool)), this, SLOT(manager_available()));
Or, better still, use the new signal/slot syntax if you're using Qt5...
connect(this->manager, &QOfonoManager::availableChanged, this, &MyClass::manager_available);
In addition to the above you should heed the advice of #scopchanov & #ixSci regarding the placement of your connect statements. It's vital that connections are established before signals are emitted otherwise the notifications will be missed.

Custom QProcess object to wait for output before returning

note: the title does not convey the question exactly, feel free to edit as is necessary
Info on classes and descriptions
Problem
Code examples, etc
TL;DR
1. Info:
I have created a custom QProcess class called m_Proc.
#include "misc_serv"
using namespace misc_serv;
class GEN_SERVSHARED_EXPORT m_Proc : public QProcess
{
Q_OBJECT
public:
int exitCode = -1;
QString _out;
s_i_combo si;
QList<s_i_combo> sch_in_List;
m_Proc(QList<s_i_combo> i_s_list, QObject *parent = 0);
m_Proc(s_i_combo i_s_obj, QObject *parent);
m_Proc(QObject *parent);
void setProcessBlocks(s_i_combo _si);
void setProcessBlocks(QList<s_i_combo> _si_list);
~m_Proc() {}
private:
s_i_combo getSearchInput();
void initConnectors();
public slots:
void myReadyReadStandardOutput();
void myFinished(int i);
signals:
void finishedSignal();
};
The purpose of this class is to use the signals emitted from the QProcess parent, which will allow me to read*() from and write() to the QProcess.
When the final output is reached, the QProcess::finished(int), is connected to a method to assign the final output and exit code of the QProcess
a signal is then emitted from m_Proc which will notify the parent class The signal named (quite creatively) finishedSignal
m_Proc is handled by another parent class named gen_serv.
#include "m_proc.h"
class GEN_SERVSHARED_EXPORT gen_serv : public QObject
{
Q_OBJECT
private:
QObject *parent;
QProcess *p;
int MSEC = 1000;
m_Proc *m;
int exitCode = -1;
QString _proc_out;
void init_connector();
private slots:
void getResults();
public:
gen_serv(QObject *_parent = new QObject());
virtual ~gen_serv();
void runCommand(const QString _prog);
void runCommand(const QString _prog, const QStringList args);
void runCommand(const QString _prog, const QString _sSearch, const QString _sInput);
void runCommand(const QString _prog, const QStringList args, const QString _sSearch, const QString _sInput);
void runCommand(const QString _prog, s_i_combo siCombo);
void runCommand(const QString _prog, const QStringList args, s_i_combo siCombo);
void runCommand(const QString _prog, QList<s_i_combo> siList);
void runCommand(const QString _prog, const QStringList args, QList<s_i_combo> siList);
QString getRunCommand_Output();
int getRunCommand_ExitCode();
QProcess* createProcess(QString cmd/*, int t_sec = 30*/);
};
gen_serv has various "constructor methods" for m_Proc. These constructor methods calls runCommand. These constructors with their parameters allow various processing capabilities ranging from a basic program execution to a detailed I/O process.
2. The Problem:
In my qt console application, I create a gen_serv object, and use this to "runCommands", e.g. :
//main.cpp
gen_serv *gen_proc
gen_proc = new gen_serv();
gen_proc->runCommand("sh", QStringList()
<< "-c"
<< "echo sleeping; sleep 2; echo hello...");
qDebug() << gen_proc->_proc_out;
based on how my m_Proc works, it will should return: "hello..."
the command to be run above is the same as (to my understanding):
$ sh -c "echo sleeping; sleep 2; echo hello..."
sleeping
hello...
BUT: it returns an empty QString, and:
qDebug() << QString::number(gen_proc->exitCode);
outputs : "-1"
3. Extra code examples, etc - This led me to believe:
the issue does not lie in m_Proc, but in my parent class gen_serv.
Currently, after calling void gen_serv::runCommand(), I run the QObject::connect() as shown below (getResults() just gets the _proc_out and exitCode and assigns them to gen_serv for accessor methods):
QObject::connect(m, SIGNAL(finishedSignal()), this, SLOT(getResults()));
However this is executed, and runCommand() returns to main.cpp where qDebug() immediately calls the gen_proc->_proc_out and qDebug() will output:
_gen_proc->_proc_out = ""
_gen_proc->exitcode = -1
4. TL;DR
What I need:
I need to devise a method which will run after/or replacing the connect (in gen_serv).
This method will wait until the signal is emitted, so the runCommand() , which calls the QProcess.start(), will not return until the finishedSignal from m_Proc is emitted, thus guaranteeing a valid output/exit code value.
Any suggestions?
I have found a solution, I cannot tell if it is a good one or not, but it works.
Possible Solution: (using QProcess::wait*()'s)
In the method (gen_serv::init_connector()) where I call the QObject::connect(), I changed/added a few extra lines.
void gen_serv::init_connector(){
if (m->waitForStarted()) {
QObject::connect(m, SIGNAL(finishedSignal()), this, SLOT(getResults()));
if (!m->waitForFinished())
qDebug() << "program is hanging, check m_Proc description for possible hang issues...: \n" << m->errorString();
}
else{
if (m->errorString().contains("No such file or directory"))
qDebug() << "check program and arguments - something seems wrong. Cannot find something... : \n" << m->errorString();
else
qDebug() << m->errorString();
}
}
The solution is pretty straight forward, but nonetheless, I will provide a short description:
Firstly, one checks if the process has actually started. If not, then display an appropriate message with the error string.
note: I noticed that an error string like:
"execp: No such file or directory usually implies that either the program is not found
i.e. incorrect path or there are surplus arguments or the application does not take any arguments
If the QProcess is started, then connect() the signal and slot. Followed by the waitForFinished().
Reason for the waitForFinished() is this method waits for the QProcess::finished(int) signal.
This allows the application to wait until the process has completed (which is what I require).
Hope this helps someone

Qt4: connect slot and signal from other forms

I have a small problem. I want run function in MainWindow from AnotherWindow. I can't set connect() for it.
Main class: MainWindow
Other form: AnotherWindow
Function in main class: setVariable(QString)
Function in other form: btnClicked()
I have now connected button signal clicked():
// In AnotherWindow.cpp
connect(ui->btnOK, SIGNAL(clicked()), this, SLOT(btnOkClicked()));
// Function in same file
void interfaceWindow::btnOkClicked() {
/* Some actions - emit signal? */
this->close();
}
btnOkClicked() are declared as private slot.
// In MainWindow.cpp
void MainWindow::setVariable(QString _var) {
this->var = _var;
}
setVariable(QString) are declared as public slot.
How I can send variable from AnotherForm (from btnOkClicked() function) to MainWindow (setVariable(QString) function) ? How and where I must send signal and make connection?
I readed about signals and slots, but my code don't work - I don't paste it here because it's terrible :)
Any help for Qt newbie?
You need to have an reference of AnotherWindow in MainWindow OR vice versa. Then you need the following things:
// AnotherWindow.h
signals:
void buttonOkClickedSignal(QString var);
// AnotherWindow.cpp
void interfaceWindow::btnOkClicked() {
emit buttonOkClickedSignal("The button got clicked!");
this->close();
}
Next step varies based on whether MainWindow has reference to AnotherWindow or vice versa. You can either:
// AnotherWindow.cpp
connect(this, SIGNAL(buttonOkClickedSignal(QString), &mainWindow, SLOT(setVariable(QString)));
or:
// MainWindow.cpp
connect(&anotherWindow, SIGNAL(buttonOkClickedSignal(QString), this, (SLOT(setVariable(QString)));
If you are invoking the slot through signal it shouldn't matter whether it's private or public (see Qt Documentation).
Hope this helps.
I'm not entirely sure I understand your question, but let me try.
You want to be able to fire a slot in another class. There are a few ways you can do that.
Declare one as a friend class to the other. Then they can see the protected and private variables/memebers
It is possible to make slots static so you can call them without a class object.
For example,
class MainWindow {
private slot:
void setVariable(QString);
}
class AnotherWindow {
friend class MainWindow;
MainWindow *window;
public:
AnotherWindow() {
connect(this, SIGNAL(fire(QString)), window, SLOT(setVariable(QString)));
}
signals:
void fire(QString);
public slots:
void onButtonClicked() {
emit fire(QString);
}
}
The previous is pseudocode so don't expect it to compile. I think this is what you want. Basically since your slot is private on MainWindow you need to make it a friend. To connect, it needs to be a member. Then when the onButtonClicked slot is evoked, then it fire()s the setVarialbe() slot.
Here is a simple code for your another window:
class MyWidget : public QWidget
{
Q_OBJECT
public:
MyWidget(QWidget * parent = 0)
{
okBtn = new QPushButton ("I am Ok!");
MyData = "";
connect(okBtn ,SIGNAL(clicked()),this,SLOT(OnOk()));
}
~MyWidget();
private:
QString MyData;
QPushButton * okBtn;
//something that modify string MyData
signals:
void MyDataSignal(QString);
//Internal slot that emits signal with proper data
private slots:
void OnOk()
{
if(MyData!="")
{
emit MyDataSignal(MyData);
}
}
};
Now in MainWindow create an object of MyWidget (suppose myWid)and connect it to slot
connect(myWid, SIGNAL(MyDataSignal(QString)),this,SLOT(OnMyWidOkClicked(QString)));
the signal will pass string to slot.
While making signals and slots keep in mind following points:
To connect a signal to a slot (or to another signal), they must have the same parameter
Parameters should be in the same order in both signal and slot.
if a signal has more parameters than the slot it is connected to, the additional parameters are simply ignored but opposite is not possible.
If you will connect a signal that have unmatched parameters to slot then no compile time error will occur but at run time command window will show a warning that signal/slot/connection does not exist.

Can Qt signals return a value?

Boost.Signals allows various strategies of using the return values of slots to form the return value of the signal. E.g. adding them, forming a vector out of them, or returning the last one.
The common wisdom (expressed in the Qt documentation [EDIT: as well as some answers to this question ]) is that no such thing is possible with Qt signals.
However, when I run the moc on the following class definition:
class Object : public QObject {
Q_OBJECT
public:
explicit Object( QObject * parent=0 )
: QObject( parent ) {}
public Q_SLOTS:
void voidSlot();
int intSlot();
Q_SIGNALS:
void voidSignal();
int intSignal();
};
Not only doesn't moc complain about the signal with the non-void return type, it seems to actively implement it in such a way as to allow a return value to pass:
// SIGNAL 1
int Object::intSignal()
{
int _t0;
void *_a[] = { const_cast<void*>(reinterpret_cast<const void*>(&_t0)) };
QMetaObject::activate(this, &staticMetaObject, 1, _a);
return _t0;
}
So: according to the docs, this thing isn't possible. Then what is moc doing here?
Slots can have return values, so can we connect a slot with a return value to a signal with a return value now? May that be possible, after all? If so, is it useful?
EDIT: I'm not asking for workarounds, so please don't provide any.
EDIT: It obviously isn't useful in Qt::QueuedConnection mode (neither is the QPrintPreviewWidget API, though, and still it exists and is useful). But what about Qt::DirectConnection and Qt::BlockingQueuedConnection (or Qt::AutoConnection, when it resolves to Qt::DirectConnection).
OK. So, I did a little more investigating. Seems this is possible. I was able to emit a signal, and receive value from the slot the signal was connected to. But, the problem was that it only returned the last return value from the multiple connected slots:
Here's a simple class definition (main.cpp):
#include <QObject>
#include <QDebug>
class TestClass : public QObject
{
Q_OBJECT
public:
TestClass();
Q_SIGNALS:
QString testSignal();
public Q_SLOTS:
QString testSlot1() {
return QLatin1String("testSlot1");
}
QString testSlot2() {
return QLatin1String("testSlot2");
}
};
TestClass::TestClass() {
connect(this, SIGNAL(testSignal()), this, SLOT(testSlot1()));
connect(this, SIGNAL(testSignal()), this, SLOT(testSlot2()));
QString a = emit testSignal();
qDebug() << a;
}
int main() {
TestClass a;
}
#include "main.moc"
When main runs, it constructs one of the test classes. The constructor wires up two slots to the testSignal signal, and then emits the signal. It captures the return value from the slot(s) invoked.
Unfortunately, you only get the last return value. If you evaluate the code above, you'll get: "testSlot2", the last return value from the connected slots of the signal.
Here's why. Qt Signals are a syntax sugared interface to the signaling pattern. Slots are the recipients of a signal. In a direct connected signal-slot relationship, you could think of it similar to (pseudo-code):
foreach slot in connectedSlotsForSignal(signal):
value = invoke slot with parameters from signal
return value
Obviously the moc does a little more to help in this process (rudimentary type checking, etc), but this helps paint the picture.
No, they can't.
Boost::signals are quite different from those in Qt. The former provide an advanced callback mechanism, whereas the latter implement the signaling idiom. In the context of multithreading, Qt's (cross-threaded) signals depend on message queues, so they are called asynchronously at some (unknown to the emitter's thread) point in time.
Qt's qt_metacall function returns an integer status code. Because of this, I believe this makes an actual return value impossible (unless you fudge around with the meta object system and moc files after precompilation).
You do, however, have normal function parameters at your disposal. It should be possible to modify your code in such a way to use "out" parameters that act as your "return".
void ClassObj::method(return_type * return_)
{
...
if(return_) *return_ = ...;
}
// somewhere else in the code...
return_type ret;
emit this->method(&ret);
You may get a return value from Qt signal with the following code:
My example shows how to use a Qt signal to read the text of a QLineEdit.
I'm just extending what #jordan has proposed:
It should be possible to modify your code in such a way to use "out" parameters that act as your "return".
#include <QtCore>
#include <QtGui>
class SignalsRet : public QObject
{
Q_OBJECT
public:
SignalsRet()
{
connect(this, SIGNAL(Get(QString*)), SLOT(GetCurrentThread(QString*)), Qt::DirectConnection);
connect(this, SIGNAL(GetFromAnotherThread(QString*)), SLOT(ReadObject(QString*)), Qt::BlockingQueuedConnection);
edit.setText("This is a test");
}
public slots:
QString call()
{
QString text;
emit Get(&text);
return text;
}
signals:
void Get(QString *value);
void GetFromAnotherThread(QString *value);
private slots:
void GetCurrentThread(QString *value)
{
QThread *thread = QThread::currentThread();
QThread *mainthread = this->thread();
if(thread == mainthread) //Signal called from the same thread that SignalsRet class was living
ReadObject(value);
else //Signal called from another thread
emit GetFromAnotherThread(value);
}
void ReadObject(QString *value)
{
QString text = edit.text();
*value = text;
}
private:
QLineEdit edit;
};
To use this, just request call();.
You can try to workaround this with following:
All your connected slots must save their results in some place (container) accessible from signaling object
The last connected slot should somehow (select max or last value) process collected values and expose the only one
The emitting object can try to access this result
Just as an idea.