Delete Objects Even Without "New"?

Probably a dumb question, but should I delete pens and rectangles and
device contexts that are created in a way, such as:  CRect RectA ?  If
so, how?

Also, when a window is closed, all its pens, device contexts, etc, are
automatically deleted, right?

Thanks,

Jim

In article < XXXX@XXXXX.COM >, 
 XXXX@XXXXX.COM  says...

When you create an object (e.g. a CRect) on the stack, you most 
certainly should NOT delete that object.

If you USE that object to create a GDI object (e.g. a DC, as in 
myBMP.CreateCompatibleBitmap) then you need to release that GDI 
object when you're done with it.  GDI objects are always created on 
the GDI heap, so they're always dynamically created and destroyed -- 
there's no direct equivalent of an automatic variable with them.


No.  When/if you end a process, the system will attempt to release 
all the resources owned by that process, but if you just close o 
window it doesn't release any resources except those that are 
associated directly with the window itself -- most of which isn't 
directly visible, such as the message queue.  About the only thing 
that can be released to which you can get more or less direct access 
is the window's DC if its class was registered with the CS_OWNDC 
style.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

In article < XXXX@XXXXX.COM >, 
 XXXX@XXXXX.COM  says...

When you create an object (e.g. a CRect) on the stack, you most 
certainly should NOT delete that object.

If you USE that object to create a GDI object (e.g. a BMP, as in 
myBMP.CreateCompatibleBitmap) then you need to release that GDI 
object when you're done with it.  GDI objects are always created on 
the GDI heap, so they're always dynamically created and destroyed -- 
there's no direct equivalent of an automatic variable with them.


No.  When/if you end a process, the system will attempt to release 
all the resources owned by that process, but if you just close o 
window it doesn't release any resources except those that are 
associated directly with the window itself -- most of which isn't 
directly visible, such as the message queue.  About the only thing 
that can be released to which you can get more or less direct access 
is the window's DC if its class was registered with the CS_OWNDC 
style.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

CRect RectA allocates a CRect on the stack. It would be meaningless to try to delete it.
Not to mention silly.

Pens, brushes, regions, etc. are a different question, because they have associated kernel
objects, represented by handles. In this case, DeleteObject can be called to explicitly
delete an object. That is usually not necessary, because normally the kernel objects are
implicitly deleted when the destructor for the C++ object is called.

An object cannot be successfully deleted if it is selected into a DC.

Typically, there is no reason to worry about DC existence, because DCs are normally
created as local variables on the stack and implicitly deleted when you leave the context.
It is unbelievably rare to have a DC held longer than the scope of a single function, that
is, the models are

void SomeFunction()
     {
	CClientDC dc(this);
                 	... do stuff here
     }

or more commonly, 

void CClass::OnPaint()
    {
     CPaintDC dc(this);
     ... do drawing
   }

Therefore, the DC has a transient existence and worrying about when it is deleted is
rarely a concern.

Pens are not owned by windows; pens are owned by applications. There is absolutely no
association between a pen and a window, as far as the kernel is concerned.

Normally, you create such associations by creating CPen, CBrush, etc. objects (not CPen *,
mind you, CPen) in the C++ class representing a window. When the C++ objects are
destroyed, their associated kernel objects are destroyed by the destructor of the
containing CWnd-derived object.  This gives the illusion that the pen is owned by the
window, but in fact it is not. The CPen variable is owned by the instance of the
CWnd-derived class, which is a somewhat different question.
				joe







Joseph M. Newcomer [MVP]
email:  XXXX@XXXXX.COM 
Web:  http://www.**--****.com/ 
MVP Tips:  http://www.**--****.com/