Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
QCompleter sets text after activated signal
JonB last edited by JonB
I have a
QCompleter. I act on the content immediately when it is completed. But then the requirement is to empty the
When the user types and presses Return I get the
QLineEdit::editingFinishedsignal, deal with the content, and clear it out --- no problem.
When the user clicks a selection from the
QCompleterI get the
QCompleter::activatedsignal. I can do what I like in that --- act on the content directly, or
QLineEdit::editingFinishedsignal which is what I actually do. I finish of by clearing the text in this slot, or whatever that calls, as above.
The problem is that after
QCompleter::activatedsignal slots have completed and returned, something in the Qt framework is then setting the attached
QLineEdittext to what the user chose. I can see a
QLineEdit::textChanged()signal for that. This means that my attempts to clear the line edit are to no avail, it gets to set to what the user selected by Qt later on.
Is there anything I can do about this? Otherwise I'm going to have a place a timer in
QCompleter::activatedslot to clear the text later....
@JonB a real quick, and possibly dirty, workaround would be to connect your QCompleter::activated signal to your slot via a Qt::QueuedConnection
JonB last edited by
Thanks. About to try now. Never used one of those so I have to figure the syntax in PyQt first!
I need the Qt internal code which raises the signal to finish off its internal populating of the line edit first. Is that what
QueuedConnectiondoes? So it pushes its intended raised signal to a queue, then completes its own stuff, and I guess hits the event lop which then raises the signal. Is that the gist?
I need the Qt internal code which raises the signal to finish off its internal populating of the line edit first. Is that what QueuedConnection does? So it pushes its intended raised signal to a queue, then completes its own stuff, and I guess hits the event lop which then raises the signal. Is that the gist?
In essence yes.
Normally all connect() are done with AutoConnect (it's the default value, when not specified). When signal and slot life in the same thread then that is a DirectConnect.
Meaning the slot is executed directly when the signal is emitted. If multiple slots are connected to the same signal, than they are executed one after the other, in order of the initial connect calls.
By forcing a QueuedConnection the slot is not executed but queued to be executed first thing, next event loop cycle.
In this case, it will have the same effect as a SingleShot timer with a timeout of 0
JonB last edited by
QueuedConnectiondoes the job for me. Thanks :)