how to properly construct derived class...
-
...so as to not get this message when using a method:
QObject: Cannot create children for a parent that is in a different thread.
My derived class:
class SerialPort : public QSerialPort { Q_OBJECT private: QByteArray buffer; public: SerialPort(); ... SerialPort::SerialPort() { ...
Thanks...
-
...so as to not get this message when using a method:
QObject: Cannot create children for a parent that is in a different thread.
My derived class:
class SerialPort : public QSerialPort { Q_OBJECT private: QByteArray buffer; public: SerialPort(); ... SerialPort::SerialPort() { ...
Thanks...
hi @mzimmers
all QObject derived classed (QSerialPort is one) should (need to) have a QObject *parent and a proper initialisation in your case:class SerialPort : public QSerialPort { Q_OBJECT private: QByteArray buffer; public: explicit SerialPort(QObject *parent = nullptr) : QSerialPort(parent) { } ... SerialPort::SerialPort() {
-
...so as to not get this message when using a method:
QObject: Cannot create children for a parent that is in a different thread.
My derived class:
class SerialPort : public QSerialPort { Q_OBJECT private: QByteArray buffer; public: SerialPort(); ... SerialPort::SerialPort() { ...
Thanks...
-
Thanks for the replies. J.Hilk: I've made the corrections you listed, and that seems to have fixed it. jsulm: the code that threw the error is:
bool SerialPort::openComPort(const QString &portName) { if (portName != nullptr) { if (isOpen()) { close(); // in case we've opened a different one. } setPortName(portName); rc = open(QIODevice::ReadWrite); // the error occurs here
The SerialPort object is created in the worker object/thread. Seems like an odd error to get in this situation.
-
Thanks for the replies. J.Hilk: I've made the corrections you listed, and that seems to have fixed it. jsulm: the code that threw the error is:
bool SerialPort::openComPort(const QString &portName) { if (portName != nullptr) { if (isOpen()) { close(); // in case we've opened a different one. } setPortName(portName); rc = open(QIODevice::ReadWrite); // the error occurs here
The SerialPort object is created in the worker object/thread. Seems like an odd error to get in this situation.
@mzimmers said in how to properly construct derived class...:
Thanks for the replies. J.Hilk: I've made the corrections you listed, and that seems to have fixed it. jsulm: the code that threw the error is:
bool SerialPort::openComPort(const QString &portName) { if (portName != nullptr) { if (isOpen()) { close(); // in case we've opened a different one. } setPortName(portName); rc = open(QIODevice::ReadWrite); // the error occurs here
The SerialPort object is created in the worker object/thread. Seems like an odd error to get in this situation.
It‘s actually not, without a parent, the Serialport is created in the mainthread and not moved with ‚‘moveToThread‘ together with its parent.
-
@mzimmers said in how to properly construct derived class...:
Thanks for the replies. J.Hilk: I've made the corrections you listed, and that seems to have fixed it. jsulm: the code that threw the error is:
bool SerialPort::openComPort(const QString &portName) { if (portName != nullptr) { if (isOpen()) { close(); // in case we've opened a different one. } setPortName(portName); rc = open(QIODevice::ReadWrite); // the error occurs here
The SerialPort object is created in the worker object/thread. Seems like an odd error to get in this situation.
It‘s actually not, without a parent, the Serialport is created in the mainthread and not moved with ‚‘moveToThread‘ together with its parent.
@J.Hilk said in how to properly construct derived class...:
@mzimmers said in how to properly construct derived class...:
The SerialPort object is created in the worker object/thread. Seems like an odd error to get in this situation.
It‘s actually not, without a parent, the Serialport is created in the mainthread and not moved with ‚‘moveToThread‘ together with its parent.
Oh...I didn't realize that. Is that because the serialPort object is created in the c'tor of the worker? If the worker created the object after it had been moved to its own thread, then the object would exist within the new thread, correct?
-
Thanks for the replies. J.Hilk: I've made the corrections you listed, and that seems to have fixed it. jsulm: the code that threw the error is:
bool SerialPort::openComPort(const QString &portName) { if (portName != nullptr) { if (isOpen()) { close(); // in case we've opened a different one. } setPortName(portName); rc = open(QIODevice::ReadWrite); // the error occurs here
The SerialPort object is created in the worker object/thread. Seems like an odd error to get in this situation.
bool SerialPort::openComPort(const QString &portName) { if (portName != nullptr)
I find this condition check suspicious for a reference input parameter.
How do you think about to omit it? -
bool SerialPort::openComPort(const QString &portName) { if (portName != nullptr)
I find this condition check suspicious for a reference input parameter.
How do you think about to omit it?@elfring openComPort() is called from a slot that's responding to a change in a selection from a QComboBox. This is just a mild safeguard against something going wrong in the selection. If anything, I probably should check that it resolves to a valid port name.
-
Hi,
You should rather use
!portName.isEmpty()
.portName
can't be a null pointer in any case. -
@J.Hilk said in how to properly construct derived class...:
@mzimmers said in how to properly construct derived class...:
The SerialPort object is created in the worker object/thread. Seems like an odd error to get in this situation.
It‘s actually not, without a parent, the Serialport is created in the mainthread and not moved with ‚‘moveToThread‘ together with its parent.
Oh...I didn't realize that. Is that because the serialPort object is created in the c'tor of the worker? If the worker created the object after it had been moved to its own thread, then the object would exist within the new thread, correct?
@mzimmers said in how to properly construct derived class...:
Oh...I didn't realize that. Is that because the serialPort object is created in the c'tor of the worker? If the worker created the object after it had been moved to its own thread, then the object would exist within the new thread, correct?
Correct