QLineEdit.setText() generating segmentation fault
I have a code which works fine without memory leaks which make a simple QDialog.
I am trying to add some text to be displayed in the QLineEdit widgets as it gets created and it generates segmentation fault:
@QLabel *step = new QLabel(tr("Line capture step"));
QLineEdit *lineStep = new QLineEdit();
connect(lineStep, &QLineEdit::textChanged, this, &inputDialog::disableOnLetters);
It does not matter how I enter the QString in setText, the result is always the same. If I debug the code, the issue is clearly at setText. I tried to clear the project and rebuild, even after restarting QT .... the problem stays.
Anybody has a suggestion where to look?
I might not be the QLineEdit! The first think I would like to mention is the parent of the QLineEdit. Set this to the dialog you are creating, that makes cleaning up of memory a thing for Qt, instead of you as programmer.
The second thing, you connect the 'textChanged' signal to a slot, so it might also be a failure in that slot!
Check that part of code as well!
Could problem be in inputDialog::disableOnLetters slot? What is happening there?
edit: fpex@ Welcome to DevNet. :)
I doubt it as the code works fine. But just in case here is the code:
@void inputDialog::disableOnLetters (const QString &text)
QRegExp re("\d*"); // a regular expression to capture digits
...... and while typing I found my error.
the setText is called before the allButtons vector is filled in the constructor.
Sorry and thanks guys!
Hi and welcome to devnet,
Where do you call setText ? From the constructor or from another function ? If another function, you are probably using a member variable that you shadowed in the constructor so your lineEdit member variable is not initialized
Hope it helps
It is indeed so. I realised while writing the previous post that calling the set text was triggering a slot resulting in accessing a vector before it was initialised.
Just for the archives, a better solution is to use textEdited() when using setText to avoid to trigger an unwanted signal/slot connection via textChanged().
One good way to approach that is to always do all widgets initialization first, then all the connection. Once that is setup, you should be able to call anything that might trigger a slot and be safe.
Changing the signal also means that your disableOnLetters won't be called at all initially so your widget might not be in the state you wanted.
I agree. In my case This is not a problema as all is designed such that that check function is needed when the text is changed in a not programmatic way.
@SGaist I wish I found your post earlier today, wasted half a day chasing my tail, investigating crazy things, just couldn't find the reason for my segmentation fault, read your post ... thought to myself ... I couldn't be that dumb ... or could I???
And yes I was, was making a reference to the a lineEdit object before I had even initalised the ui frrl like a dope, but at least the seg fault has gone ;-)