On Friday 11 December 2009 07:28:27 Henning Schröder wrote: > I have looked at the source of QPlainTextEdit and QTextEdit. Actually the > implementations are not consistent. > QPlainTextEdit calls verticalBar.blockSignals(True) before it call setValue > which would otherwise emit valueChanged.
Hi guys, hi Henning, This is what's awesome about this mailing-list: you bring up the most obscure issue, and there's someone with a helpful and interesting answer for you. Brilliant! In my case I worked around the problem by sending the signal manually after calling triggerAction(). Not very clean, but that's workarounds for you. But in the meanwhile more QPlainTextEdit weirdness crept up. As part of a helpful little feature that shows you the bottom of your text in a split screen while you scroll back, I use the awesome QTextDocument.drawContents() method. In short, you feed it a QPainter and a QRectF and it does what it says on the label: a slice of your document as delineated by the QRectF is rendered onto the QPainter. There is, as far as I can tell, no difference between the QTextDocument returned by QTextEdit.document() and QPlainTextEdit.document(). Same class in both cases. And yet in the latter case, drawContents() renders nothing at all. Cursory investigation points to a different QAbstractTextDocumentLayout implementation under the hood depending on the TextEdit flavor in use. So I think I'm going to drop QPlainTextEdit entirely, even though in theory it's better suited to my problem domain. After a few tests, the benefits in speed and memory usage are not obvious anyway. (Which is possibly a testament to QTextEdit's efficiency, when you think of it.) But alternative viewpoints would be welcome! Bye, -- S. _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt