TextChanged triggered in QPlainTextEdit even if signals blocked when using QSyntaxHighlighter

[fscibilia]

Hi all,

I'm using QPlainTextEdit with QSyntaxHighlighter with signals blocked in QPlainTextEdit. I'm using a test code like this (within the constructor of a class derived by QMdiSubWindow):

@
editor_ = new QPlainTextEdit("Hello", this);
editor_->blockSignals(true);
connect(editor_, SIGNAL(textChanged()), SLOT(onTextChanged()));
editor_->textCursor().insertText(text);
ScriptSyntaxHighlighter* highlighter = new ScriptSyntaxHighlighter(editor_->document());
setWidget(editor_);
editor_->blockSignals(false);
@

Strangely, while the instruction
@
textCursor().insertText()
@

does not trigger textChanged (as expected due to signals area blocked), the instruction
@
new ScriptSyntaxHighlighter(editor_->document())
@

triggers the signal (even if it invoked while signals are blocked). However, I noted that the in the first case (insertText), the signal is emitted in DirectConnection with slots invoked immediately, while the textChanged() triggered by QSyntaxHighlighter is emitted in QueuedConnection at the end of the GUI event loop (after the blockSignals set to false).

Even if not a bug, I think it is an unwanted behaviour.

Any suggestion? May be is a bug? Any workaround? At the moment, I'm simply ignoring the first signal emitted (not elegand but anyway working).

Thanks
Fabio

[SGaist]

Hi,

What happens if you first set the highlighter and then the text ?

[fscibilia]

Hi SGaist,

I tried your suggestion and it works. The new snippet is this one:

@
editor_ = new QPlainTextEdit("Hello", this);
editor_->blockSignals(true);
ScriptSyntaxHighlighter* highlighter = new ScriptSyntaxHighlighter(editor_->document());
connect(editor_, SIGNAL(textChanged()), SLOT(onTextChanged()));
editor_->textCursor().insertText(text);
setWidget(editor_);
editor_->blockSignals(false);
@

With the above code no signals are emitted. It seems to me that setting the syntax highlighter after the insertion of a text produces the emission of a new textChanged() signals in the next GUI even loop (some cascade of signals produced in QueuedConnection). This is a bit misleading for the programmer :(.

In any case my problem is solved, thanks for your help

Fabio

[SGaist]

Was textChanged triggered only once or repeatedly with your original code ?