[Qt-interest] Trying to understand Signal/slots.

[phil prentice]

Thankyou Thiago

Thank you for your answer which has helped me a lot and I am pleased that Qt 
works the way it does.  Its exactly what I want.  My error was that I thought 
a modal dialog would block the main event loop because it blocks the 
application , preventing any other processing or interactions from taking 
place until the dialog is closed (obviously interactions still take place 
with the modal dialog).

I was not quite sure how it did that and assumed that one possibility was that 
it would use its own event loop somehow, and so stop the parents event 
loop...the parents code seems to be waiting for the dialog to return 
anyway....but its obviously does not work that way.
It obviously still uses the same event loop(parents), but blocks/disables the 
parent from receiving any user interactions...I'm beginning to see that 
now!!!

Signal/slots are great, but as you have probably gathered I do find them a 
little confusing when they are used across different threads.  I need to 
create myself a list of rules as to how things work across different threads.
I will start with the answers you have kindly given me!!
I will also consult the "You're doing it wrong" blog.

Thanks very much again for your help

Phil

On Saturday 21 August 2010 18:51, Thiago Macieira wrote:
> On Saturday 21. August 2010 17.25.55 phil prentice wrote:
> > If I open a modeless dialog in one of my application windows I would have
> > half  expected that any new openVIwindow signals would not be serviced
> > until the modeless dialog returned so freeing up the event loop of the
> > main application?
>
> If you're showing a dialog, the event loop is being run. That's how events
> from the system are received and processed.
>
> This includes events carrying queued signal emissions.
>
> If you want such signals not to be serviced, you need to write such code
> yourself.
>
> > I assume that the emit signal would have caused a queued signal to be
> > sent to  the main application because its being sent from a different
> > thread?  Is this assumption where I've got it wrong?
>
> No. That assumption is correct.
>
> Your went wrong when you assumed that showing a dialog blocked the event
> loop.
>
> > Is what I am doing wrong the fact that m_iconThread object was created in
> > the  same thread as the applications so regardless of which thread is
> > doing the emitting, the slot is being called directly and so the actual
> > run thread is creating the new window itself directly.....which I assume
> > is a BIG NO-NO?
>
> The thread the signal emitter belongs to is irrelevant. You're right in the
> fact that the m_iconThread object belongs to its creating thread, not to
> the thread that it started.
>
> But a connection is queued if the target object's thread is not the same as
> the current thread. When the signal is emitted from run(), it becomes
> queued and is posted via an event from that thread into the main thread.
>
> Emitting signals from classes derived from QThread is ok. The big NO-NO is
> the use of slots in such classes (see the "You're doing it wrong" blog).
>
> > I am very happy with the way the application is working at the moment,
> > but I  just think that I'm just doing it wrong?? And I will probably get
> > problems later???