QObject::blockSignals(true) not blocking QTextEdit->textChanged() signal

[ce_nort]

I have a bunch of UI objects with their signals connected to a `registerChange()` slot. I do not want this slot to be triggered when I am initially populating the existing data, so I use `blockSignals()`. This works great for everything except the QTextEdit object, which still successfully triggers `registerChange()`. Any idea why this would be? If my understanding of `blockSignals` is correct then this shouldn't be possible. Stripped down code for context:


ContactWindow::ContactWindow()
{
...
connect(ui->first_name_edit, SIGNAL(textEdited(QString)), this, SLOT(registerChange()));
connect(ui->last_name_edit, SIGNAL(textEdited(QString)), this, SLOT(registerChange()));
connect(ui->email_edit, SIGNAL(textEdited(QString)), this, SLOT(registerChange()));
connect(ui->notes_edit, SIGNAL(textChanged()), this, SLOT(registerChange()));
...
}

void ContactWindow::populateData()
{
// Block signals while setting
this->blockSignals(true);

// Populate UI fields
ui->first_name_edit->setText(current_contact.first_name);
ui->last_name_edit->setText(current_contact.last_name);
ui->email_edit->setText(current_contact.email);
ui->notes_edit->setText(current_contact.notes); // This signal still gets caught.

// Unblock signals
this->blockSignals(false);
}

[Ginsengelf]

Hi, the docs say

If block is true, signals emitted by this object are blocked
so I think you need to set it for "ui->notes_edit" and not for "this".

Ginsengelf

[ce_nort]

Hi, the docs say

so I think you need to set it for "ui->notes_edit" and not for "this".

Ginsengelf

Okay, that does make sense, but then why does it work for every other UI element?

[Ginsengelf]

Hi, I was wondering about that myself when I wrote the answer. No idea.

Ginsengelf

[ce_nort]

Huh, I guess some things will remain mysterious. Thanks for your help!