[PyQt] QThread, Slots, Signals, meta type information error
corbelligiuseppe at mesdan.it
Tue Mar 5 07:58:25 GMT 2019
On 3/4/19 5:09 PM, Repscher, Benedikt wrote:
> Thank you for your reply.
> I read the article "you're doing it wrong" and learned some things
> from it. However, it didn't help me resolve my issue.
> I sort of resvoled the issue.
> I discovered the difference because the code that I actually use
> looks a little bit different (uses 2 QThreads). However, this code raised the
> same error, even though it uses the moveTothread()-approach.
> The code that I posted here that uses the moveToThread()-approach
> works, because the signal belongs to the same object as the slot.
> Therefore, Qt seems to use a Qt.DirectConnection (non-queued).
> However, when you want to use QueuedConnection (which is the default
> when usign the QThread-subclassing-approach) then the connection fails
> because of lacking meta-info.
> Therefore, IMHO, the problem with missing meta-info still persists.
> The moveToThread()-approach just works around the issue, because it
> doesn't use the queued connection.
> Consider the matter closed.
Well, not really :-)
I don't have a pyqt+btle installation but, strictly Qt speaking:
"A single QMetaObject instance is created for each QObject subclass that
is used in an application [...]"
And QBluetoothDeviceInfo is not a QObject subclass.
AFAIK (little and less, admittedly) however your issue is related to the
serialization that must be done to copy the object so that the target
thread can have its own instance. In turn this means that QMetaType info
should be available for the class, and in fact it is by looking at the
Q_DECLARE_METATYPE(QBluetoothDeviceInfo) line in qbluetoothdeviceinfo.h
So basically I cannot be of much help, since everything seems to be in
the right place.
Did you try the connection without the pyqtSlot decorator?
Out of curiosity: why are you explicitly calling the underlying
thread().exec_() in a QObject moved to that thread?
More information about the PyQt