There are some rules that make life with signals and slots easier and cover the most common reason for defective connections. If I forgot something please tell me. 1) Check the debug console output: When execution errors occur, the debug output can show you the reason. 2) Use the full signature of signal and slot: … Read more
As I found out in the last days… the Qt way of doing this is like this: class IEmitSomething { public: virtual ~IEmitSomething(){} // do not forget this signals: // <- ignored by moc and only serves as documentation aid // The code will work exactly the same if signals: is absent. virtual void someThingHappened() … Read more
No. Signals cannot be public or private. Qt signals are protected class methods. “signals” keyword is defined in qobjectdefs.h (line 69 as for Qt 4.6.1): # define signals protected UPDATE: signals are only protected upto and including all minor versions of Qt 4. From Qt 5.0 onwards they are public. See https://stackoverflow.com/a/19130831.
You won’t see much of a difference unless you’re working with objects having different thread affinities. Let’s say you have QObjects A and B and they’re both attached to different threads. A has a signal called somethingChanged() and B has a slot called handleChange(). If you use a direct connection connect( A, SIGNAL(somethingChanged()), B, SLOT(handleChange()), … Read more
Yes, the QObject::~QObject destructor takes care of that: All signals to and from the object are automatically disconnected, and any pending posted events for the object are removed from the event queue. However, it is often safer to use deleteLater() rather than deleting a QObject subclass directly. Do take care though: Warning: Deleting a QObject … Read more
There are quite a few problems with your code : like said by Evan the emit keyword is missing all your objects live in the main thread, only the code in the run methods live in other threads, which means that the MySlot slot would be called in the main thread and I’m not sure … Read more
Deleting QObjects is usually safe (i.e. in normal practice; there might be pathological cases I am not aware of atm), if you follow two basic rules: Never delete an object in a slot or method that is called directly or indirectly by a (synchronous, connection type “direct”) signal from the object to be deleted. E.g. … Read more