Slot must be public?

riph72

Hello all,

I have a very simple main() that creates two objects (of different classes), one object sends a signal to a slot in the other object.

Now what puzzles me is that I have to define the slot as public, else my application won't compile. However, I'd read that signals & slots could be connected even if the slot was private - private only affected the external calling access when not using signals/slots.

Is this something that has changed in recent versions of Qt, or have I just misunderstood things?

Regards,
Richard.

BjornW

Private slots can only be connected from inside the object (for example in its constructor). Public slots can be connected from anywhere (for example in your main function)

Edit: I realized this is not exactly what you asked. I do not know if this is a change or not. Do you use the new qt5 syntax to connect (member function pointers)? or the old SIGNAL() SLOT() syntax?

riph72

I am using the new Qt5 syntax - from main(), modified slightly for readability:

QObject::connect(&objectA, &ClassA::my_signal, &objectB, &ClassB::my_slot);

raven-worx

@riph72
no, the visibility is just for the case when calling the method directly via C++.
Since slots are called from the object's meta-object (which is a friend class / member of this object) the actual visibility doesn't matter.

riph72

Well, I seem to be experiencing the opposite! The "public slots" function is only used as a slot (i.e. via a signal, with no other references), but if I make it private, my build breaks.

kshegunov

@raven-worx, However to be able to take the address of a method you have to comply with the scope of said method, thus &ClassB::my_slot is only valid if your scope (public, private, protected) allows you to take the address. This means that if you connect from outside the class the scope rules apply and you must have the method declared as public.

@riph72 If you want to enforce slots to be private, then you must make your connects from within the class, it's just how it works. (The old-style connect breaks the semantics of scope for slots, as @BjornW correctly remarked)

raven-worx

@riph72
@kshegunov

of course this is right for the new function pointer connect syntax.
Don't know how i could over read this... sry

riph72

@kshegunov That's fine thanks - I don't want to enforce my slots as private, I just wanted to understand why making it private didn't work, for my understanding... I don't like it when I fix things but don't understand how!