[Qt-interest] signals and slots, combination and execution order

[hilbert at beuth-hochschule.de]

On Wed, 10 Jun 2009 17:47:02 -0400, John McClurkin wrote
> hilbert at beuth-hochschule.de wrote:
> > hello,
> > 
> > i have a QLineEdit with the signal 'editingFinished()' connected 
to 'slot1
> > ()'. there is also a QPushButton with the signal 'clicked()' connected 
to 
> > another 'slot2()'. as to be expected: when the text in the QLineEdit is 
> > changed and the QPushButton ist clicked both slots are executed. in my 
> > case 'slot1()' is always called first. in some cases i need to execute a 
> > QMessegeBox::question(...) in 'slot1()' and wait for the return value of 
the 
> > question box. if this is the case, the QPushButton hangs (at least 
visually) 
> > in the 'pressed' state and 'slot2()' is never called. the 'clicked()'-
signal 
> > of the QPushButton seems to be lost even when the connection is set to 
> > Qt::QueuedConnection. is there an easy or at least a reasonable way to 
solve 
> > this problem without tricky event-handling?
> > 
> > no other threads than the main-gui-thread are involved at this stage of 
the 
> > programm. i already tested a bit with an event filter. as far as i got 
the 
> > event for the button release seems to be eaten up by the modal 
> > QMessegeBox::question dialog. for me it would be awkward to ask for any 
> > QPushButton states in slot1 (and when to do this would generate further 
> > difficulties)...
> > 
> > and how could i possibly determine the order of the calls?
> > 
> > thanx & best regards,
> > andreas
> > --
> > Open WebMail Project (http://openwebmail.org)
> I think you have a basic problem with this design. According to the 
> docs, a button's clicked signal is emitted when the button is 
> released, but QLineEdit object will loose focus and emit its 
> editingFinished signal when the button is pressed. Because you are 
> posting a modal dialog in the slot connected to the editingFinished 
> signal, the clicked signal from the button is lost. 

that's exactly what i found out now. seems to be easy at first but get's far 
more complex than expected. i'm sure now that slot1() always will be 
executed 1st, thats comforting... but i'll have to check focus change and 
button events and act accordingly. would have been better to force the user 
to confirm a change in the lineEdit by pressing return and leave the 
pushButtons as they were...