Does Qt guarantee the order of focus (out and in) signals ?



  • I'm having some problems with the order of focus out/in signals when running in SDI mode on the OSX platform (the fact that the problem only appears in this specific configuration puzzles me the most) using Qt 4.7.
    It seems as if in my configuration a push button would get it's click signal before an edit controls get's is focus lost signal.
    I already discovered that changing the focus policy of the enclosing QWidget to Qt::StrongFocus seems to fix the problem but after reading the documentation this seems more like magic and it still do not understand the cause of the original problem nor why the change in the focus policy fixed it.

    1. Does Qt actually guarantee that I always get a focus lost signal before (any) other signal (in my case the click on the push button) ?
    2. How should setting the focus policy on a QWidget (not a QDialog) as the main window enclosing other widgets affect the ordering of signals ?
    3. is there any specific documentation that explain in detail the order of signals in general and/or in in my specific circumstances ?

  • Moderators

    If I recollect correctly, signals and slots are ordered by moc in the same order the connections were established. So, it may well be that this is the cause: button's click signal was connected before edit's focus one. But that's just a guess.

    To be honest, why do you think this order is wrong? You do the click, so button sends the clicked signal, and then the edit looses focus - because the button has it now. Seems OK to me. Would be quite strange if edit lost focus before the click happened.



  • [quote author="sierdzio" date="1324453377"]If I recollect correctly, signals and slots are ordered by moc in the same order the connections were established. So, it may well be that this is the cause: button's click signal was connected before edit's focus one. But that's just a guess.
    [/quote]

    I know the same.

    [quote author="sierdzio" date="1324453377"]
    To be honest, why do you think this order is wrong? You do the click, so button sends the clicked signal, and then the edit looses focus - because the button has it now. Seems OK to me. Would be quite strange if edit lost focus before the click happened.[/quote]

    Well, clicking a button means that the component (button) gets the focus, so the other one should have loose the focus too.



  • That guarantee about signal order refers to the order in which a series of slots connected to the same signal on the same object will be called. Nothing more, nothing less. The order in which signals are emitted is independent from this. Dieter is asking about the order in which signals will be emitted: will the focus lost happen before the focus received of another widget?

    I don't know the answer to Dieters question. What's more, I think there are no signals for these things at all, just events. I do understand the question and I think it is a valid one. If you assume that there is always one, and ony one widget in a dialog that has focus, then neither of the event orders makes sense. Say, the focus is in a line edit, and the user clicks a button. Considder these three event sequences:

    LineEdit::focusOut → Button::focusIn → Button::click

    Button::focusIn → LineEdit::focusOut → Button::click

    Button::click → LineEdit::focusOut → Button::focusIn

    All of them are weird. The first one has a brief moment where no widget has focus, while the second one seems to have a moment while two widgets have focus. The last one at first sight seems to be the most logical (having the thing that causes the focus change first), but the button click is really not an event, but a sequence of itself. The reality is probably even more complicated and looks something like this:

    Button::mouseDown → lineEdit::focusOut → button::focusIn → button::mouseUp → button::click

    Perhaps you can avoid any depence on this order, if you use QApplication::focusChanged instead of relying on the order. However, this signal (this is a signal) is send only after both widgets have already been send the FocusEvent.



  • Thank you for all the feedback:

    1. Some more information:

    Clarification: I understand that the signals from one widget come in the order of the connect statements but as Andre correctly stated, my problem relates to single signals from multiple widgets.

    Motivation: the problem typically appears when a edit control needs to do some computations when the focus is lost and the results are shown in another field. In this case "our" program logic expects that those computations are already done (during focus lost) before we process the push button (click).

    [quote author="Andre" date="1324461511"]Perhaps you can avoid any depence on this order, if you use QApplication::focusChanged instead of relying on the order. However, this signal (this is a signal) is send only after both widgets have already been send the FocusEvent. [/quote]
    I absolutely agree that this should be the way to go and this is also what we generally try to do but especially when there are complex relationships between the edit fields (stuff like default values that need to calculated from others fields but can later be changed by the user) this gets really complicated.

    1. Some questions that might help to better understand:

    2.1) What should setting the focus policy of a QWidget as a main window for other controls do ?

    2.2) When and why should the focus policy been changed in general ?

    2.3) Is there any sequence of signals/events that we can rely on in Qt or is it just "random" ?


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.