QLineEdit combined with QStackedWidget, crash

[JonB]

@Wenchi
You don't say, but I assume that ui->lineEdit is on stacked widget #0 and there is a another, different page at stacked widget #1?

You might get some indication what is going on if you place a breakpoint at the start of lineEdit_textChanged() and look at the stack trace as it keeps getting hit. You should also look at the stack trace when it "crashes".

[Wenchi]

@JonB the three controls is independent with each other

[JonB]

@Wenchi
So the lineEdit is not on either of the stacked widget pages --- how would we ever have known this? The stacked widget just has two blank QWidgets in it.

OK. But what about using the debugger as everyone is saying to see what is going on?

Meanwhile: do you just type in test once? Because everything looks like you are appending test to the line edit on textChanged() signal somewhere? Use that debugger to see....

[Wenchi]

@JonB
I insert a break point, and have clicked "run" for 3 times.

Then I canceled the breakpoint and run. The stack overflowed and it crashed.
By the way, just intput sth by Chinese input method, and don't press "Enter" to make it finish.

[Bonnie]

Wow, surprisingly I can reproduce that even in debug mode. This does seem to have some bug caused by repeatly gaining and losing focus.
Only need to type one "test" then output endless

[debug]MainWindow::on_lineEdit_textChanged(126):on_lineEdit_textChanged "test"
[debug]MainWindow::on_lineEdit_textChanged(126):on_lineEdit_textChanged "testtest"
[debug]MainWindow::on_lineEdit_textChanged(126):on_lineEdit_textChanged "testtesttest"
[debug]MainWindow::on_lineEdit_textChanged(126):on_lineEdit_textChanged "testtesttesttest"
[debug]MainWindow::on_lineEdit_textChanged(126):on_lineEdit_textChanged "testtesttesttesttest"
[debug]MainWindow::on_lineEdit_textChanged(126):on_lineEdit_textChanged "testtesttesttesttesttest"
[debug]MainWindow::on_lineEdit_textChanged(126):on_lineEdit_textChanged "testtesttesttesttesttesttest"

But I haven't got time to debug it through yet.

[Wenchi]

@Bonnie I just tried it out yet in debug mode : )

[JonB]

@Wenchi
If @Bonnie is on it (a) I would guess he is not using "Chinese input method", so that's not it, and (b) he will track it down!

But just so I understand (because I do not). You write "under the Chinese input method ", but I don't know what that is/how it works. Do I take it that it shows you that "bar" of possible inputs (numbered 1 to 7), you click on 1 test and that inserts test into the line edit, just once? Since I assume @Bonnie has reproduced without that it does not seem relevant, but I would like to understand.

If you look carefully at your stack trace you can see that lineEdit_textChanged() is indeed calling itself recursively, as suspected, hence the eventual "crash".

Meanwhile, I would guess --- bug or not --- that there is something "wrong" with "changing focus while you are inside the textChanged() signal handler", something assumes the focus will not change from the QLineEdit it is currently handling. And that somehow makes it keep "re-seeing" the same original test input and adding it. If this is so, you may have to do the ui->stackedWidget->setCurrentIndex(1); call from a QTimer::singleShot() you set off in your slot....

[Wenchi]

@JonB
First allow me to explain the "Chinese input method":
When I input "test":

Then I can click "1"(or "2" or "3"...) or press "Enter" and the input is finished and this status won't cause crash:

If I click somewhere else, the input is not finished and this status can cause crash:

To fix this problem, I add the code "blockSignals":

void MainWindow::lineEdit_textChanged(const QString &arg1)
{
    qDebug()<<"on_lineEdit_textChanged"<<arg1;
    ui->lineEdit->blockSignals(true);
    ui->stackedWidget->setCurrentIndex(1);
    ui->lineEdit->blockSignals(false);
}

[JonB]

@Wenchi
OK, now I know (a bit) about how "Chinese input" works! But I suspect this itself is not the issue, assuming @Bonnie is reproducing the issue.

I am not a great fan of blockSignals(), one is never sure what the side-effects ignoring signals might be. Given that I suggested that QLineEdit might not having like focus changed while inside textChanged() signal, what about the QTimer alternative I suggested instead of blocking signals:

QTimer::singleShot(0, [this]() { ui->stackedWidget->setCurrentIndex(1); });

[Wenchi]

@JonB QTimer::singleShot works! It's more convenient than blockSignals()! Adore you!

[JonB]

@Wenchi Thank you, but I am not necessarily very adorable ;-)

[Bonnie]

@JonB said in QLineEdit combined with QStackedWidget, crash:

If @Bonnie is on it (a) I would guess he is not using "Chinese input method", so that's not it, and (b) he will track it down!

No, I'm using it actually :)
I've done debugging.
Because QStackedWidget::setCurrentIndex calls QWidget::clearFocus which makes the window to emit a focusObjectChanged signal (no matter it actually had the focus or not).
And during the application handling that, it finds the input method composing, so it send a QInputMethodEvent by sendEvent to commit the string and end the composition after that.
But while the line edit handling the event, it emits textChanged again so that never ends.
Not sure whether that is a bug or not...Maybe we are just not supposed to change focus within textChanged()

[JonB]

@Bonnie said in QLineEdit combined with QStackedWidget, crash:

No, I'm using it actually :)

Oh! @Bonnie does not sound like a very Chinese name :)

Maybe we are just not supposed to change focus within textChanged()

That is evidently the case. For whatever reason, it appears the internals expect the line edit to have the focus while dealing with textChanged(), and changing it causes the signal to be re-emitted.