Replace Qt with TQt

Signed-off-by: Michele Calgaro <[email protected]>

1 files changed, 1 insertions, 1 deletions

diff --git a/doc/man/man3/tqscrollview.3qt b/doc/man/man3/tqscrollview.3qt
index 188d4b098..e271ad2b3 100644
--- a/doc/man/man3/tqscrollview.3qt
+++ b/doc/man/man3/tqscrollview.3qt
@@ -413,7 +413,7 @@ To enable drag-and-drop, you would setAcceptDrops(TRUE) on the QScrollView (beca
 .PP
 To handle mouse events on the scrolling area, subclass scrollview as you would subclass other widgets, but rather than reimplementing mousePressEvent(), reimplement contentsMousePressEvent() instead. The contents specific event handlers provide translated events in the coordinate system of the scrollview. If you reimplement mousePressEvent(), you'll get called only when part of the QScrollView is clicked: and the only such part is the "corner" (if you don't set a cornerWidget()) and the frame; everything else is covered up by the viewport, clipper or scroll bars.
 .PP
-When you construct a QScrollView, some of the widget flags apply to the viewport() instead of being sent to the TQWidget constructor for the QScrollView. This applies to WNoAutoErase, WStaticContents, and WPaintClever. See Qt::WidgetFlags for documentation about these flags. Here are some examples:
+When you construct a QScrollView, some of the widget flags apply to the viewport() instead of being sent to the TQWidget constructor for the QScrollView. This applies to WNoAutoErase, WStaticContents, and WPaintClever. See TQt::WidgetFlags for documentation about these flags. Here are some examples:
 .IP
 .TP
 An image-manipulation widget would use \fCWNoAutoErase|WStaticContents\fR because the widget draws all pixels itself, and when its size increases, it only needs a paint event for the new part because the old part remains unchanged.