QObject::connect returns false

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

KroMignon

@SPlatten said in QObject::connect returns false:

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

In this header signal signature is void updateTime(int) and not void updateTime(long)

JonB

@SPlatten
class clsTimeSync : public clsSchdSrv {
Although updateTime() is only a slot and not a signal, you do not have Q_OBJECT in this class. Does it help if you do (and then rebuild from scratch)?

JonB

@KroMignon said in QObject::connect returns false:

In this header signal signature is void updateTime(int) and not void updateTime(long)

That's coz he has changed per earlier on.
I agree we do not know for sure what his code is, but I think he dealt with that alteration.

SPlatten

@J-Hilk , why? The class it inherits already has that.

SPlatten

@KroMignon , because I changed it from long to int after earlier posts.

JonB

@SPlatten said in QObject::connect returns false:

@J-Hilk , why? The class it inherits already has that.

That's not how it works. Which is why I said to try putting Q_OBJECT in.

Can you please do that and then we will discuss why if it makes any difference?

SPlatten

@JonB , adding Q_OBJECT to the inherit class results in the compiler error:

undefined erference to `vtable for clsTimeSync`

jsulm

@SPlatten said in QObject::connect returns false:

results in the compiler error

You need to do a complete rebuild

KroMignon

@SPlatten said in QObject::connect returns false:

why? The class it inherits already has that.

Because it is a Qt recommendation (cf. https://doc.qt.io/qt-5/metaobjects.html)

The meta-object system is based on three things:

The QObject class provides a base class for objects that can take advantage of the meta-object system.

The Q_OBJECT macro inside the private section of the class declaration is used to enable meta-object features, such as dynamic properties, signals, and slots.

The Meta-Object Compiler (moc) supplies each QObject subclass with the necessary code to implement meta-object features.

SPlatten

@KroMignon , @JonB , @J-Hilk , @jsulm , ok, works now I think the missing Q_OBJECT was the issue as having cleaned out the build folder, remake, rebuild, now it works.

JonB

@jsulm said in QObject::connect returns false:

You need to do a complete rebuild

As we have said over & over again, it would be nice if people followed that instead of ignoring it.....

JonB

@SPlatten said in QObject::connect returns false:

@J-Hilk , why? The class it inherits already has that.

Q_OBJECT is a macro. You can look at what it does.

I know the rule is:

Every class which defines signals MUST have Q_OBJECT in that class definition. Inheritance from parent is not what it's about.
Normally I believe slot-only classes do not have to have Q_OBJECT. HOWEVER I only work with the new-style connect() syntax, not available in Qt4. It may be that to use SLOT() you do also need Q_OBJECT in old style? When in doubt --- and certainly if I were having a problem --- I would put Q_OBJECT into classes with slots just in case.....