0

QT signals are by default protected, which means they can be emitted in the object but can be listened anywhere.

But some signals are implementation details and I'm struggling to find a way to not let it go out of the class scope.

Is there a way to do it?

Update:

I want to use signals because I want to queue some lower priority tasks rather than handle them promptly at the point of emit/call. Is it a bad idea to use Qt::QueuedConnection for this purpose?

user3528438
  • 2,737
  • 2
  • 23
  • 42
  • 2
    I'm having trouble understanding why you wouldn't just use a callback function in this instance? – Jonathan Mee Mar 19 '15 at 17:03
  • If the signal is an "implementation details", then instead of emitting the signal, just call the appropriate functions? – JBL Mar 19 '15 at 17:07
  • 1
    I agree with @JonathanMee. Qt's signals are not meant for internal use, they're meant for allowing generic subscribers to listen, without your needing to know of or be concerned about their details. That does not fit your use case here, so don't use a signal for this. – mah Mar 19 '15 at 17:07
  • @JonathanMee For some lower priority tasks that is better to be queued rather than handled promptly. Is it a bad idea to use Qt::QueuedConnection for this purpose? – user3528438 Mar 19 '15 at 17:13
  • See [this answer](http://stackoverflow.com/a/19130831/4673641) – jhnnslschnr Mar 19 '15 at 17:17
  • @user3528438 The fact that you want to queue the message indicates you want to track state with something else in your design, rather than updating the business logic before the front end populates. A better plan would be to have your GUI element you're trying to sync with signal the business logic it's changes. – Jonathan Mee Mar 19 '15 at 17:22
  • @JonathanMee This is actually used in the business logic. It's a counter in the middle of some computation. The counter emits other signals to sync with other objects depending some conditions. The counter is very tolerant to delays and it just makes much more sense to queue it to the completion of business logic that has tighter real-time constant. – user3528438 Mar 19 '15 at 17:37
  • You can create a fully private QObject-derived class, i.e. don't provide its declaration in public headers. Make your public class a friend of the private class to allow sending the latter's signals from the former. Another way is to use `QMetaObject::invokeMethod` with `Qt::QueuedConnection`, which is pretty much more direct way to put something in the queue. – Pavel Strakhov Mar 19 '15 at 21:50

0 Answers0