Any type is allowed with direct connections. But I assume you have a queued connection (thread A to thread B). Here you have to inform Qt about your type with QMetaType - but it's strange that quint32 is unknown...
Any type is allowed with direct connections. But I assume you have a queued connection (thread A to thread B). Here you have to inform Qt about your type with QMetaType - but it's strange that quint32 is unknown...
yes, that's right, sender and receiver of the signal are living in different threads...
I don't know exactly how the signal / slot system works but I have an idea why you can't use quint32: In the connect you have to specify the type as a name, which is converted to a const char* by a macro. But how should the compiler guess that "unsigned int" is equal to "quint32"?
Another problem is that the quint8 seems to work OR that the parameters are queued from right to left. Then connect could stop after the quint32.
My suggestion is that you try to use unsigned int or do you really need exactly 32 bit, with more being an error?
sorry, i forgot a quint32 as the first parameter in the signal/slot signature.
so most probably it goes from left to right and stops already when reading the first quint32.
rewrote the signals/slot with ordinary ints and up to now it's working.
Bookmarks