QObject::connect returns false

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 ?

KroMignon

@SPlatten said in QObject::connect returns false:

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

Some time Qt-Creator do not detect changes is HEADERS files, so moc will not be re-run.
This is why I suggest you to try to re-run yourself qmake and, if this not help, remove the build directory (as also suggested by @JonB ) to force full rebuild (with moc).

But first, make sure all headers are present in HEADERS of your PRO file.

SPlatten

@J-Hilk , clsSchdSrv.h, still a early work in progress:

class clsSchdSrv : public QTimer {
    Q_OBJECT

public:
    explicit clsSchdSrv(QObject* pParent = 0);
    void kick();

public slots:
    virtual void expired() = 0;
}

Sorry, should have added:

class clsTimeSync : public clsSchdSrv {
public:
    explicit clsTimeSync();

public slots:
    virtual void expired();
    void updateTime(int intTimeNow);
}

JonB

@SPlatten
We have all said several times to try a complete delete and re-build.....

jsulm

@SPlatten You should see a warning at runtime when connect is executed: what does it say?

SPlatten

@KroMignon, I deleted the content of the build folder , checking for any hidden files, then ran clean, remake and build, same results.

J.Hilk

@SPlatten if thats the header, than I as well fail to see the slot void updateTime(long); declaration ;)

JonB

@SPlatten said in QObject::connect returns false:

public slots:
virtual void expired() = 0;

But you use SLOT(updateTime())?

Why are you showing us clsSchdSrv? Earlier you showed clsTimeSync?

KroMignon

@SPlatten said in QObject::connect returns false:

clsSchdSrv.h, still a early work in progress:

I am not sure, you can declare a slot as virtual.
I would change this to:

class clsSchdSrv : public QTimer {
    Q_OBJECT

public:
    explicit clsSchdSrv(QObject* pParent = 0);
    void kick();

public:
     virtual void  onExpired() = 0;
public slots:
    void expired() {  onExpired(); } 
}

SPlatten

@JonB , please see the edited post which includes the derived class, sorry.

J.Hilk

@SPlatten your derived class will need the Q_OBJECT macro as well, if it defines slots/signals