\helpref{wxGDIObject}{wxgdiobject}\\
\helpref{wxObject}{wxobject}
+\wxheading{Include files}
+
+<wx/brush.h>
+
+\wxheading{Predefined objects}
+
+Objects:
+
+{\bf wxNullBrush}
+
+Pointers:
+
+{\bf wxBLUE\_BRUSH\\
+wxGREEN\_BRUSH\\
+wxWHITE\_BRUSH\\
+wxBLACK\_BRUSH\\
+wxGREY\_BRUSH\\
+wxMEDIUM\_GREY\_BRUSH\\
+wxLIGHT\_GREY\_BRUSH\\
+wxTRANSPARENT\_BRUSH\\
+wxCYAN\_BRUSH\\
+wxRED\_BRUSH}
+
\wxheading{Remarks}
-On a monochrome display, wxWindows shows
+On a monochrome display, wxWidgets shows
all brushes as white unless the colour is really black.
Do not initialize objects on the stack before the program commences,
wxBrush uses a reference counting system, so assignments between brushes are very
cheap. You can therefore use actual wxBrush objects instead of pointers without
-efficiency problems. Bear in mind, though, that changing a brush's properties may
-affect another brush which has been involved in an assignment with the first brush,
-because of the way internal brush data is shared.
-
-TODO: an overview for wxBrush.
+efficiency problems. Once one wxBrush object changes its data it will create its
+own brush data internally so that other brushes, which previously shared the
+data using the reference counting, are not affected.
+%TODO: an overview for wxBrush.
\wxheading{See also}
\helpref{wxBrushList}{wxbrushlist}, \helpref{wxDC}{wxdc}, \helpref{wxDC::SetBrush}{wxdcsetbrush}
\latexignore{\rtfignore{\wxheading{Members}}}
-\membersection{wxBrush::wxBrush}
+\membersection{wxBrush::wxBrush}\label{wxbrushctor}
\func{}{wxBrush}{\void}
Default constructor. The brush will be uninitialised, and \helpref{wxBrush::Ok}{wxbrushok} will
-return FALSE.
+return false.
-\func{}{wxBrush}{\param{const wxColour\&}{ colour}, \param{int}{ style}}
+\func{}{wxBrush}{\param{const wxColour\&}{ colour}, \param{int}{ style = {\tt wxSOLID}}}
Constructs a brush from a colour object and style.
Copy constructor. This uses reference counting so is a cheap operation.
-\func{}{wxBrush}{\param{const wxBrush*}{ brush}}
-
-Copy constructor. This uses reference counting so is a cheap operation.
-
\wxheading{Parameters}
\docparam{colour}{Colour object.}
\begin{twocollist}\itemsep=0pt
\twocolitem{{\bf wxTRANSPARENT}}{Transparent (no fill).}
\twocolitem{{\bf wxSOLID}}{Solid.}
+\twocolitem{{\bf wxSTIPPLE}}{Uses a bitmap as a stipple.}
\twocolitem{{\bf wxBDIAGONAL\_HATCH}}{Backward diagonal hatch.}
\twocolitem{{\bf wxCROSSDIAG\_HATCH}}{Cross-diagonal hatch.}
\twocolitem{{\bf wxFDIAGONAL\_HATCH}}{Forward diagonal hatch.}
\helpref{wxBrushList}{wxbrushlist}, \helpref{wxColour}{wxcolour}, \helpref{wxColourDatabase}{wxcolourdatabase}
-\membersection{wxBrush::\destruct{wxBrush}}
+\membersection{wxBrush::\destruct{wxBrush}}\label{wxbrushdtor}
\func{void}{\destruct{wxBrush}}{\void}
Although all remaining brushes are deleted when the application exits,
the application should try to clean up all brushes itself. This is because
-wxWindows cannot know if a pointer to the brush object is stored in an
+wxWidgets cannot know if a pointer to the brush object is stored in an
application data structure, and there is a risk of double deletion.
\membersection{wxBrush::GetColour}\label{wxbrushgetcolour}
\constfunc{wxBitmap *}{GetStipple}{\void}
Gets a pointer to the stipple bitmap. If the brush does not have a wxSTIPPLE style,
-this bitmap may be non-NULL but uninitialised (\helpref{wxBitmap::Ok}{wxbitmapok} returns FALSE).
+this bitmap may be non-NULL but uninitialised (\helpref{wxBitmap::Ok}{wxbitmapok} returns false).
\wxheading{See also}
\twocolitem{{\bf wxHORIZONTAL\_HATCH}}{Horizontal hatch.}
\twocolitem{{\bf wxVERTICAL\_HATCH}}{Vertical hatch.}
\twocolitem{{\bf wxSTIPPLE}}{Stippled using a bitmap.}
+\twocolitem{{\bf wxSTIPPLE\_MASK\_OPAQUE}}{Stippled using a bitmap's mask.}
\end{twocollist}
\wxheading{See also}
\constfunc{bool}{Ok}{\void}
-Returns TRUE if the brush is initialised. It will return FALSE if the default
+Returns true if the brush is initialised. It will return false if the default
constructor has been used (for example, the brush is a member of a class, or
NULL has been assigned to it).
\wxheading{Remarks}
-The style will be set to wxSTIPPLE.
+The style will be set to wxSTIPPLE, unless the bitmap has a mask associated
+to it, in which case the style will be set to wxSTIPPLE\_MASK\_OPAQUE.
-Note that there is a big difference between stippling in X and Windows.
-On X, the stipple is a mask between the wxBitmap and current colour.
-On Windows, the current colour is ignored, and the bitmap colour is used.
-However, for pre-defined modes like wxCROSS\_HATCH, the behaviour is the
-same for both platforms.
+If the wxSTIPPLE variant is used, the bitmap will be used to fill out the
+area to be drawn. If the wxSTIPPLE\_MASK\_OPAQUE is used, the current
+text foreground and text background determine what colours are used for
+displaying and the bits in the mask (which is a mono-bitmap actually)
+determine where to draw what.
+
+Note that under Windows 95, only 8x8 pixel large stipple bitmaps are
+supported, Windows 98 and NT as well as GTK support arbitrary bitmaps.
\wxheading{See also}
\twocolitem{{\bf wxHORIZONTAL\_HATCH}}{Horizontal hatch.}
\twocolitem{{\bf wxVERTICAL\_HATCH}}{Vertical hatch.}
\twocolitem{{\bf wxSTIPPLE}}{Stippled using a bitmap.}
+\twocolitem{{\bf wxSTIPPLE\_MASK\_OPAQUE}}{Stippled using a bitmap's mask.}
\end{twocollist}}
\wxheading{See also}
\helpref{wxList}{wxlist}\\
\helpref{wxObject}{wxobject}
+\wxheading{Include files}
+
+<wx/gdicmn.h>
+
\wxheading{Remarks}
There is only one instance of this class: {\bf wxTheBrushList}. Use
`memory leaks'. However, it is best not to rely on this automatic
cleanup because it can lead to double deletion in some circumstances.
-There are two mechanisms in recent versions of wxWindows which make the
+There are two mechanisms in recent versions of wxWidgets which make the
brush list less useful than it once was. Under Windows, scarce resources
are cleaned up internally if they are not being used. Also, a referencing
counting mechanism applied to all GDI objects means that some sharing
your application is using too many resources, you can resort to using
GDI lists to share objects explicitly.
-The only compelling use for the brush list is for wxWindows to keep
+The only compelling use for the brush list is for wxWidgets to keep
track of brushes in order to clean them up on exit. It is also kept for
-backward compatibility with earlier versions of wxWindows.
+backward compatibility with earlier versions of wxWidgets.
\wxheading{See also}
\func{void}{AddBrush}{\param{wxBrush *}{brush}}
-Used internally by wxWindows to add a brush to the list.
+Used internally by wxWidgets to add a brush to the list.
\membersection{wxBrushList::FindOrCreateBrush}\label{wxbrushlistfindorcreatebrush}
\func{void}{RemoveBrush}{\param{wxBrush *}{brush}}
-Used by wxWindows to remove a brush from the list.
+Used by wxWidgets to remove a brush from the list.
projects / wxWidgets.git / blobdiff