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

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:

Code:

---

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);
}

---

Hi, the docs say

Quote:

---

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

Quote:

---

Originally Posted by Ginsengelf

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?

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

Ginsengelf

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