QObject::connect returns false

J.Hilk

@SPlatten is this potentially cross thread ?

or more in general, the long typdef may not be correctly registered with the meta system.

you could use qint32, that should work.

SPlatten

@JonB , so the source now reads:

Q_ASSERT(pobjEmulator);
Q_ASSERT(pobjService);
bool blnRC(QObject::connect(pobjEmulator, SIGNAL(epoch(long))
                           ,pobjService, SLOT(updateTime(long))));

Built and run, no assertions, blnRC is false.

SPlatten

@J-Hilk , no, not at the moment, this is just simple test code, nothing complex at all....just literally creating instances of each, call to connect and that is it.

JonB

@J-Hilk said in QObject::connect returns false:

or more in general, the long typdef may not be correctly registered with the meta system.

long, really??

SPlatten

@JonB , whats wrong ?

JonB

@SPlatten
Sorry, what's wrong with what?
My previous post was just expressing surprise to @J-Hilk that long type might not be "registered with the meta system", but he knows more than I....

KroMignon

@J-Hilk said in QObject::connect returns false:

or more in general, the long typdef may not be correctly registered with the meta system.

But this would not affect to connect() call, only slot may not be called if sender and receiver not in same thread.

For my comprehension of QObject signals/slots, connect() will only fail if no machting signal or slot signature are found in meta-data. Which are generated by moc.

SPlatten

I changed long to int just to be sure, same result.

JonB

@SPlatten said in QObject::connect returns false:

Built and run, no assertions, blnRC is false.

Just checking: how do you know that? I wouldn't trist that if you are only viewing in debugger, as I believe you sometimes do; are you actually outputting the variable's value?

SPlatten

@KroMignon I will look at the generated moc files, but as you can see from my posts the prototypes are identical.

SPlatten

@JonB , I have a break point in the debugger after the connect and can see it contains false.

JonB

@SPlatten
Per @KroMignon, just start by emptying out your build output directory and doing a complete rebuild, just in case. Always start there when Qt gives you something "inexplicable" :)

KroMignon

@JonB said in QObject::connect returns false:

My previous post was just expressing surprise to @J-Hilk that long type might not be "registered with the meta system", but he knows more than I..

For inter-thread communication, or in case of Qt::QueuedConnection, parameters needs to be copied. So QMeta needs to know how to create a copy of them. This is way all types needs to be registered. Some are already registered my Qt, some not ;)

JonB

@SPlatten said in QObject::connect returns false:

@JonB , I have a break point in the debugger after the connect and can see it contains false.

Noooo.
Like I said, print it out........

SPlatten

@JonB, just did that adding:

qDebug() << "connect: " << blnRC;

Shown in console as:

connect: false

JonB

@SPlatten
OK, damn!
Just I warn you now: do not rely on what you see in the debugger for values of variables...!

KroMignon

@SPlatten said in QObject::connect returns false:

I will look at the generated moc files, but as you can see from my posts the prototypes are identical.

Are you sure header files are in HEADERS in your PRO file?
Did you (re)run qmake?
You could also try to remove the build directory to force moc re-run.

JonB

@SPlatten
Like I said, have you done a delete and fresh rebuild?
Does clsTimeEmu have Q_OBJECT in it?

SPlatten

@J-Hilk , @JonB , @KroMignon , I've looked at both moc files, moc_clsTimeEmu.cpp has the signal:

// SIGNAL_0
void clsTimeEmu::epoch(int _t1)
{
    void *_a[] = { 0, const_cast<void*>reinterpret_cast<const void*>(&_t)) };
    QMetaObject::activate(this, &staticMetaObject, 0, _a);
}

moc_clsSchdSrv.cpp does not have anything that looks like the slot, no mention of updateTime at all, why ?

J.Hilk

@SPlatten well, can you post more of the clsSchdSrv header ?