59 lines
4.0 KiB
TeX
59 lines
4.0 KiB
TeX
@@TreeImage.htm
|
|
<TITLE Tree image and tree window>
|
|
|
|
Some methods in Virtual Treeview work with an internal tree image, e.g. painting or hit determination. This tree image
|
|
does not really exist but is rather an imagination of the entire tree drawn to an infinitely sized sheet. In this picture
|
|
the tree is always drawn at position (0, 0) and advances to positive horizontal and vertical values which reach out to
|
|
the right and down, respectively. This also means that coordinates given in this fictional image are always positive.
|
|
|
|
|
|
|
|
A display function like the WM_PAINT handler can now take a rectangle of this full image (in PaintTree this is called the
|
|
<U>window</U>) and let it draw to any location in a target canvas. This allows to draw a part of the entire image even if
|
|
the tree window is scrolled or needs otherwise to be moved (e.g. when dragging or printing). In order to get the full
|
|
dimension of the tree image call GetTreeRect, which returns a rectangle always starting at (0, 0) and extending at least
|
|
to client area size but usually much further (determined by the private variables FRangeX and FRangeY which also
|
|
determine the scroll bar values).
|
|
|
|
|
|
|
|
In order to maintain the visual portion of the tree image two offset values are maintained which specify the horizontal
|
|
and vertical distance relative to the client area of the tree control. These offsets (OffsetX, OffsetY and OffsetXY) are
|
|
therefore negative. This means 0 means no offset at all and -100 means the tree is scrolled by 100 pixels. Values \> 0
|
|
are always made to 0.
|
|
|
|
|
|
|
|
How does this now fit together when you want, say, to print a part of the tree to a memory or printer canvas? Have a look
|
|
at the image below:
|
|
|
|
<IMAGE TreeWindow>
|
|
|
|
On the left pane you can see a typical tree view of which only a specific part is visible. This situation is visualized
|
|
by the non-shaded rectangular region. The right pane shows the reproduction of the visible part to different locations.
|
|
The entire tree image size corresponds to the internal FRangeX and FRangeY variables of the tree view. When drawing a
|
|
part of the window the method PaintTree needs to know the size and position of the part to draw. This is given by a TRect
|
|
structure passed in the <B>Window</B> parameter. For normal screen display this rectangle structure consists of the
|
|
current scroll offsets (properties OffsetX and OffsetY or OffsetXY for both together given as TPoint) and the size of the
|
|
client area of the tree control. This rectangle is usually also intersected with the current clipping region to avoid
|
|
painting parts of the tree which are not invalid.
|
|
|
|
|
|
|
|
The place where the image is to be painted is given in the parameter <B>Target</B>. This point specifies the physical
|
|
location in the target canvas where to draw the content of the region specified by <B>Window</B>. Note that these
|
|
coordinates are usually (but wrongly) considered as being physical pixels. This might be true for screen or bitmap output
|
|
but is not for the printer where a single pixel would be much too small. Hence another term is used here: logical
|
|
coordinates. The actual size of one unit of these coordinates can either be a single pixel but also a millimeter, inch or
|
|
even some other odd size. The interpretation is determined by the mapping mode of the target canvas (device context, DC)
|
|
and its window and viewport extents. For more information about mapping modes see the online help or MSDN under <I>SetMapMode</I>
|
|
and for DC extents under <I>SetWindowExtEx</I> as well as <I>SetViewportExtEx</I>. With the help of mapping modes and
|
|
window/viewport extents you can greatly customize the outcome of PaintTree. These APIs are usually also used to provide a
|
|
print preview.
|
|
|
|
Summary
|
|
If you are one of those developers who want to create tree descendants, which perhaps involve visual changes in Virtual
|
|
Treeview then you need to know how the control paints itself (as outlined in <LINK PaintCycles.htm, Paint cycles and stages>).
|
|
What happens with the resulting image and how it can be used for certain tasks like printing? Some answers are in this
|
|
topic.
|