[Qt-interest] Forcing a signal "emit" to be queued

[Mandeep Sandhu]

On Mon, Mar 21, 2011 at 12:33 PM, Andre Somers <andre at familiesomers.nl> wrote:
> Op 21-3-2011 7:30, Mandeep Sandhu schreef:
>> Hi All,
>>
>> Sometime back I had a requirement where I didn't want ppl using my
>> class's signals to connect to them directly. Currently if you do 'emit
>> mySignal()', it's upto to the class that uses this signal, to decide
>> how it would like to connect to it.
>>
>> For forcing a queued a connection, I thought of the following approach:
>>
>> connect(this, SIGNAL(myInternalSignal(), this, SIGNAL(mySignal()),
>> Qt::QueuedConnection);
>>
>> Basically I'm chaining my signal and re-emitting it with the queued
>> connection type (I've yet to verify this code though).
>>
>> How can one verify if the slot is indeed called in a queued connection?
> Seems like a way to force preventing a direct connection, yes. However,
> please be aware that there are no private signals. Every signal is
> public. What's more, there is no access control on slots either. If you
> really want your signal to be private, then you need to emit it from a
> private internal class.

Yes, I'm aware that access control is discarded by signal-slot macro magic.

Keeping a private class for private signals seems like a good way to
enforce access control. Thanks.

>
> To verify if your pattern works, a simple debug session would suffice.
> Just put a breakpoint at the emit and start stepping though the code,
> or, if you want, put a breakpoint in the connected slot, and check the
> stack trace. A direct connected slot will have the class that emitted
> the signal in the stack, a queued connection will have the eventloop as
> the source of the call.

Right. Will try this approach.

-mandeep

>
> André
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-interest
>