1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
<HTML>
<head><title>GDI objects</title></head>
<BODY BGCOLOR=#FFFFFF>
<A NAME="gdiobjects"></A><CENTER>
<A HREF="port.htm"><img align=center src="contents.gif" BORDER=0 ALT="Contents"></A> <A HREF="port.htm"><img align=center src="up.gif" BORDER=0 ALT="Up"></A> <A HREF="port6.htm#classhierarchy"><img align=center src="back.gif" BORDER=0 ALT="Previous"></A> <A HREF="port8.htm#dialogscontrols"><img align=center src="forward.gif" BORDER=0 ALT="Next"></A> </CENTER><HR>
<H2>GDI objects</H2>
<P>
These objects - instances of classes such as wxPen, wxBrush, wxBitmap (but not wxColour) -
are now implemented with reference-counting. This makes assignment a very cheap operation,
and also means that management of the resource is largely automatic. You now pass <I>references</I> to
objects to functions such as wxDC::SetPen, not pointers, so you will need to derefence your pointers.
The device context does not store a copy of the pen
itself, but takes a copy of it (via reference counting), and the object's data gets freed up
when the reference count goes to zero. The application does not have to worry so much about
who the object belongs to: it can pass the reference, then destroy the object without
leaving a dangling pointer inside the device context.<P>
For the purposes of code migration, you can use the old style of object management - maintaining
pointers to GDI objects, and using the FindOrCreate... functions. However, it is preferable to
keep this explicit management to a minimum, instead creating objects on the fly as needed, on the stack,
unless this causes too much of an overhead in your application.<P>
At a minimum, you will have to make sure that calls to SetPen, SetBrush etc. work. Also, where you pass NULL to these
functions, you will need to use an identifier such as wxNullPen or wxNullBrush.<P>
</BODY></HTML>
|
