The TQScrollView is a large canvas - potentially larger than the coordinate system normally supported by the underlying window system. This is important because it is quite easy to go beyond these limitations (e.g. many web pages are more than 32000 pixels high). Additionally, the TQScrollView can have TQWidgets positioned on it that scroll around with the drawn content. These sub-widgets can also have positions outside the normal coordinate range (but they are still limited in size).
To provide content for the widget, inherit from TQScrollView, reimplement drawContents() and use resizeContents() to set the size of the viewed area. Use addChild() and moveChild() to position widgets on the view.
To use TQScrollView effectively it is important to understand its widget structure in the three styles of use: a single large child widget, a large panning area with some widgets and a large panning area with many widgets.
The first, simplest usage of TQScrollView (depicted above), is appropriate for scrolling areas that are never more than about 4000 pixels in either dimension (this is about the maximum reliable size on X11 servers). In this usage, you just make one large child in the TQScrollView. The child should be a child of the viewport() of the scrollview and be added with addChild():
Here the TQScrollView has four children: the viewport(), the verticalScrollBar(), the horizontalScrollBar() and a small cornerWidget(). The viewport() has one child: the big QVBox. The QVBox has the three TQLabel objects as child widgets. When the view is scrolled, the QVBox is moved; its children move with it as child widgets normally do.
The second usage of TQScrollView (depicted above) is appropriate when few, if any, widgets are on a very large scrolling area that is potentially larger than 4000 pixels in either dimension. In this usage you call resizeContents() to set the size of the area and reimplement drawContents() to paint the contents. You may also add some widgets by making them children of the viewport() and adding them with addChild() (this is the same as the process for the single large widget in the previous example):
Here, the TQScrollView has the same four children: the viewport(), the verticalScrollBar(), the horizontalScrollBar() and a small cornerWidget(). The viewport() has the three TQLabel objects as child widgets. When the view is scrolled, the scrollview moves the child widgets individually.
The final usage of TQScrollView (depicted above) is appropriate when many widgets are on a very large scrolling area that is potentially larger than 4000 pixels in either dimension. In this usage you call resizeContents() to set the size of the area and reimplement drawContents() to paint the contents. You then call enableClipper(TRUE) and add widgets, again by making them children of the viewport(), and adding them with addChild():
Here, the TQScrollView has four children: the clipper() (not the viewport() this time), the verticalScrollBar(), the horizontalScrollBar() and a small cornerWidget(). The clipper() has one child: the viewport(). The viewport() has the same three labels as child widgets. When the view is scrolled the viewport() is moved; its children move with it as child widgets normally do.
Note that the widget you see in the scrolled area is the viewport() widget, not the TQScrollView itself. So to turn mouse tracking on, for example, use viewport()->setMouseTracking(TRUE).
To enable drag-and-drop, you would setAcceptDrops(TRUE) on the TQScrollView (because drag-and-drop events propagate to the parent). But to work out the logical position in the view, you would need to map the drop co-ordinate from being relative to the TQScrollView to being relative to the contents; use the function viewportToContents() for this.
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 TQScrollView 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.
When you construct a TQScrollView, some of the widget flags apply to the viewport() instead of being sent to the TQWidget constructor for the TQScrollView. This applies to WNoAutoErase, WStaticContents, and WPaintClever. See TQt::WidgetFlags for documentation about these flags. Here are some examples:
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.
.IP
.TP
A scrolling game widget in which the background scrolls as the characters move might use WNoAutoErase (in addition to WStaticContents) so that the window system background does not flash in and out during scrolling.
.IP
.TP
A word processing widget might use WNoAutoErase and repaint itself line by line to get a less-flickery resizing. If the widget is in a mode in which no text justification can take place, it might use WStaticContents too, so that it would only get a repaint for the newly visible parts.
.IP
.PP
Child widgets may be moved using addChild() or moveChild(). Use childX() and childY() to get the position of a child widget.
.PP
A widget may be placed in the corner between the vertical and horizontal scrollbars with setCornerWidget(). You can get access to the scrollbars using horizontalScrollBar() and verticalScrollBar(), and to the viewport with viewport(). The scroll view can be scrolled using scrollBy(), ensureVisible(), setContentsPos() or center().
.PP
The visible area is given by visibleWidth() and visibleHeight(), and the contents area by contentsWidth() and contentsHeight(). The contents may be repainted using one of the repaintContents() or updateContents() functions.
.PP
Coordinate conversion is provided by contentsToViewport() and viewportToContents().
.PP
The contentsMoving() signal is emitted just before the contents are moved to a new position.
\fBWarning:\fR TQScrollView currently does not erase the background when resized, i.e. you must always clear the background manually in scrollview subclasses. This will change in a future version of TQt and we recommend specifying the WNoAutoErase flag explicitly.
\fCTQScrollView::Default\fR - the TQScrollView selects one of the other settings automatically when it has to. In this version of TQt, TQScrollView changes to Manual if you resize the contents with resizeContents() and to AutoOne if a child is added.
\fCTQScrollView::AutoOneFit\fR - if there is only one child widget the contents stays the size of that widget's sizeHint(). If the scrollview is resized larger than the child's sizeHint(), the child will be resized to fit. If there is more than one child, the behavior is undefined.
.SH "TQScrollView::ScrollBarMode"
This enum type describes the various modes of TQScrollView's scroll bars.
The widget flags WStaticContents, WNoAutoErase and WPaintClever are propagated to the viewport() widget. The other widget flags are propagated to the parent constructor as usual.
Inserts the widget, \fIchild\fR, into the scrolled area positioned at (\fIx\fR, \fIy\fR). The position defaults to (0, 0). If the child is already in the view, it is just moved.
.PP
You may want to call enableClipper(TRUE) if you add a large number of widgets.
.SH "void TQScrollView::contentsContextMenuEvent ( QContextMenuEvent * e )\fC [virtual protected]\fR"
This event handler is called whenever the TQScrollView receives a contextMenuEvent() in \fIe\fR: the mouse position is translated to be a point on the contents.
.SH "void TQScrollView::contentsMouseDoubleClickEvent ( QMouseEvent * e )\fC [virtual protected]\fR"
This event handler is called whenever the TQScrollView receives a mouseDoubleClickEvent(): the click position in \fIe\fR is translated to be a point on the contents.
.SH "void TQScrollView::contentsMouseMoveEvent ( QMouseEvent * e )\fC [virtual protected]\fR"
This event handler is called whenever the TQScrollView receives a mouseMoveEvent(): the mouse position in \fIe\fR is translated to be a point on the contents.
.SH "void TQScrollView::contentsMousePressEvent ( QMouseEvent * e )\fC [virtual protected]\fR"
This event handler is called whenever the TQScrollView receives a mousePressEvent(): the press position in \fIe\fR is translated to be a point on the contents.
.SH "void TQScrollView::contentsMouseReleaseEvent ( QMouseEvent * e )\fC [virtual protected]\fR"
This event handler is called whenever the TQScrollView receives a mouseReleaseEvent(): the release position in \fIe\fR is translated to be a point on the contents.
.SH "void TQScrollView::contentsWheelEvent ( QWheelEvent * e )\fC [virtual protected]\fR"
This event handler is called whenever the TQScrollView receives a wheelEvent() in \fIe\fR: the mouse position is translated to be a point on the contents.
Reimplement this function if you are viewing a drawing area rather than a widget.
.PP
The function should draw the rectangle (\fIclipx\fR, \fIclipy\fR, \fIclipw\fR, \fIcliph\fR) of the contents using painter \fIp\fR. The clip rectangle is in the scrollview's coordinates.
.PP
For example:
.PP
.nf
.br
{
.br
// Fill a 40000 by 50000 rectangle at (100000,150000)
.br
.br
// Calculate the coordinates...
.br
int x1 = 100000, y1 = 150000;
.br
int x2 = x1+40000-1, y2 = y1+50000-1;
.br
.br
// Clip the coordinates so X/Windows will not have problems...
.br
if (x1 < clipx) x1=clipx;
.br
if (y1 < clipy) y1=clipy;
.br
if (x2 > clipx+clipw-1) x2=clipx+clipw-1;
.br
if (y2 > clipy+cliph-1) y2=clipy+cliph-1;
.br
.br
// Paint using the small coordinates...
.br
if ( x2 >= x1 && y2 >= y1 )
.br
p->fillRect(x1, y1, x2-x1+1, y2-y1+1, red);
.br
}
.br
.fi
.PP
The clip rectangle and translation of the painter \fIp\fR is already set appropriately.
.SH "void TQScrollView::drawContentsOffset ( TQPainter * p, int offsetx, int offsety, int clipx, int clipy, int clipw, int cliph )\fC [virtual protected]\fR"
The default implementation translates the painter appropriately and calls drawContents(TQPainter*,int,int,int,int). See drawContents() for an explanation of the parameters \fIp\fR, \fIoffsetx\fR, \fIoffsety\fR, \fIclipx\fR, \fIclipy\fR, \fIclipw\fR and \fIcliph\fR.
When a large numbers of child widgets are in a scrollview, especially if they are close together, the scrolling performance can suffer greatly. If \fIy\fR is TRUE the scrollview will use an extra widget to group child widgets.
.PP
Note that you may only call enableClipper() prior to adding widgets.
.PP
For a full discussion, see this class's detailed description.
This is an overloaded member function, provided for convenience. It behaves essentially like the above function.
.PP
Scrolls the content so that the point \fI(x, y)\fR is visible with at least the \fIxmargin\fR and \fIymargin\fR margins (if possible, otherwise centered).
This event filter ensures the scroll bars are updated when a single contents widget is resized, shown, hidden or destroyed; it passes mouse events to the TQScrollView. The event is in \fIe\fR and the object is in \fIobj\fR.
Calls repaint() on a rectangle defined by \fIx\fR, \fIy\fR, \fIw\fR, \fIh\fR, translated appropriately. If the rectangle is not visible, nothing is repainted. If \fIerase\fR is TRUE the background is cleared using the background color.
All widgets set here will be deleted by the TQScrollView when it is destroyed unless you separately reparent the widget after setting some other corner widget (or 0).
Called when the horizontal scroll bar geometry changes. This is provided as a protected function so that subclasses can do interesting things such as providing extra buttons in some of the space normally used by the scroll bars.
.PP
The default implementation simply gives all the space to \fIhbar\fR. The new geometry is given by \fIx\fR, \fIy\fR, \fIw\fR and \fIh\fR.
Sets the margins around the scrolling area to \fIleft\fR, \fItop\fR, \fIright\fR and \fIbottom\fR. This is useful for applications such as spreadsheets with "locked" rows and columns. The marginal space is \fIinside\fR the frameRect() and is left blank; reimplement drawFrame() or put widgets in the unused area.
Sets the scrollview to have a static background if \fIy\fR is TRUE, or a scrolling background if \fIy\fR is FALSE. By default, the background is scrolling.
Called when the vertical scroll bar geometry changes. This is provided as a protected function so that subclasses can do interesting things such as providing extra buttons in some of the space normally used by the scroll bars.
.PP
The default implementation simply gives all the space to \fIvbar\fR. The new geometry is given by \fIx\fR, \fIy\fR, \fIw\fR and \fIh\fR.
Calls update() on a rectangle defined by \fIx\fR, \fIy\fR, \fIw\fR, \fIh\fR, translated appropriately. If the rectangle is not visible, nothing is repainted.
This is a low-level painting routine that draws the viewport contents. Reimplement this if drawContents() is too high-level (for example, if you don't want to open a TQPainter on the viewport). The paint event is passed in \fIpe\fR.
Returns the viewport size for size (\fIx\fR, \fIy\fR).
.PP
The viewport size depends on \fI(x, y)\fR (the size of the contents), the size of this widget and the modes of the horizontal and vertical scroll bars.
.PP
This function permits widgets that can trade vertical and horizontal space for each other to control scroll bar appearance better. For example, a word processor or web browser can control the width of the right margin accurately, whether or not there needs to be a vertical scroll bar.
If this property is set to TRUE (the default), the TQScrollView automatically scrolls the contents in drag move events if the user moves the cursor close to a border of the view. Of course this works only if the viewport accepts drops. Specifying FALSE disables this autoscroll feature.
\fBWarning:\fR Enabling this property might not be enough to effectively turn on autoscrolling. If you put a custom widget in the TQScrollView, you might need to call TQDragEvent::ignore() on the event in the dragEnterEvent() and dragMoveEvent() reimplementations.
