Qt::QueuedConnection not working with some object

Question

In my application, we have a simple connection between signal slot.

    connect(&A, SIGNAL(signal(myObject)), &B, SLOT(slot(myObject));

This connection, unfortunately, will lead to a recursion. Then we changed it into

    connect(&A, SIGNAL(signal(myObject)), &B, SLOT(slot(myObject)), Qt::QueuedConnection);

and it does not work anymore. The slot is never called.

I tried changing myObject for a QString and it works as expected. So the problem is something in myObject that Qt does not like so much.

I checked Class Qt.ConnectionType, Signals & Slots and QObject doc, looking for Qt::QueuedConnection but I have not found a clarification for my situation.

Some notes about my code:

The myObject is destructed just after the emission of the signal. But it should not be a problem, a copy could have been made (as I suppose is for QString, that has not this problem, I mean, even if I pass a temporary QString and destroy it right after the emission of the signal, the slot is anyway called as expected)
myObject is NOT a QObject, and noone of its members are a QObject (if it can have some influence)
myObject CAN be copied
My application is SINGLE thread
myObject has NO default constructor (but I do not think it should influence it, since a copy could be made)
I am using Qt 5.7

Does anyone have some clarification for this problem?

Actually, the documentation of Qt::QueuedConnection seems not so detailed, see the links I posted above. Do you have some more useful link?

does it print anything in output windows after executing `connect`? — pat, Jul 27 '18 at 13:30
@G.M. I will, but for the moment, let me reformulate the question :) Do you have a documentation link of Qt, to understand better what are the conditions that the arguments of the signal/slot must be subjected to? (from my problem, I suppose there should be some condition, but I could not find information about it.) — n3mo, Jul 27 '18 at 13:35
@Pham Anh Tuan you mean something like "No such signal/slot" warning? no, i checked it.... — n3mo, Jul 27 '18 at 13:37
@n3mo yes, that's why I mean. So the `connect` is fine. Make sure `B` object is not destroyed before emitting signal, and signal emits after `connect`. — pat, Jul 27 '18 at 13:49
A and B are never destroyed, they live along all the program. — n3mo, Jul 27 '18 at 13:51

score 4 · Accepted Answer · answered Jul 27 '18 at 13:33

4

Register your myObject by:

qRegisterMetaType<MyObject>("myObject");

where MyObject is the class name. doc

Between, Qt::QueuedConnection is for connection over threads, your are using threads?

answered Jul 27 '18 at 13:33

Phiber

I will test your suggestion, thanks. I do not have threads, I just have a recursion that I want to avoid. – n3mo Jul 27 '18 at 13:40
@n3mo to avoid the recursion you have to change the connecting, not the connection type. – Thomas Jul 27 '18 at 13:54
4

@Phiber even though `QueuedConnection` is most often used with threads, in general it just puts the signal on top of the objects owning threads event loop stack, so you can also use that without multiple threads. – Rudolfs Bundulis Jul 27 '18 at 13:56
@Rudolfs I agree – Phiber Jul 27 '18 at 14:02
It is the right answer indeed. If you want to add to your answer, I think the following two links are useful to understand better [Custom Type Example](http://doc.qt.io/qt-5/qtcore-tools-customtype-example.html) and [Queued Custom Type Example](http://doc.qt.io/qt-5/qtcore-threads-queuedcustomtype-example.html), in particular quoting: _To register a custom type for use with queued signals and slots, such as those used in cross-thread communication, see the Queued Custom Type Example._ I did not know that QueuedSignals worked differently from normal ones. Thanks – n3mo Jul 27 '18 at 14:07
In Qt 5, there's no need to pass the class name to `qRegisterMetaType`. It's done automatically - inside of `Q_DECLARE_METATYPE`. All you need is a raw `qRegisterMetaType()` call. – Kuba hasn't forgotten Monica Jul 27 '18 at 16:00

1 Answers1