Temporary MFC Objects

Joseph Koral -- jkoral@ftp.com
Wednesday, January 24, 1996

First, I should state my understanding of "undocumented" as it applies =
to MFC.  Anything that is private or implementation specific (i.e. =
follows the // implementation comment) is undocumented and subject to =
change in later versions. =20


There are three public methods in CImageList that I'm assuming were =
accidentally left out of the documentation, FromHandle, =
FromHandlePermanent and DeleteTempMap.   If you look at the class =
definition, they all fall under the // attributes comment and are not =
implementation specific.  Furthermore, these methods are identical in =
purpose to CWnd documented methods of the same name.

Assuming that documentation accidentally left them out, I think there is =
a problem:

Temporary objects that are created from handles are stored in maps and =
deleted during application idle time (there are other times, but it's =
not relevant).  Or if you like, each class has a DeleteTempMap for you =
to do it proactively. =20

The global function that frees the temporary maps is AfxUnlockTempMaps =
(found in WINHAND.CPP).  Among other things, it eventually calls each =
class' static DeleteTempMap method.  Only a few MFC classes will create =
temporary objects, namely CWnd, CGdiObject, CDC, CMenu, and CImageList.  =
But AfxUnlockTempMaps doesn't call the static CImageList::DeleteTempMap. =
=20

So unless I'm mistaken, if you create temporary CImageList objects, they =
will slowly consume memory as your app runs.

(On a similar note, why is CAsyncSocket::FromHandle not called =
CAsyncSocket::FromHandlePermanent?  Since CAsyncSocket won't create a =
temporary object, using FromHandle is misleading, especially when the =
identical functionality is called FromHandlePermanent in other classes). =


- Joseph

---

Joseph Koral -- jkoral@ftp.com
Wednesday, January 24, 1996

First, I should state my understanding of "undocumented" as it applies =
to MFC.  Anything that is private or implementation specific (i.e. =
follows the // implementation comment) is undocumented and subject to =
change in later versions. =20


There are three public methods in CImageList that I'm assuming were =
accidentally left out of the documentation, FromHandle, =
FromHandlePermanent and DeleteTempMap.   If you look at the class =
definition, they all fall under the // attributes comment and are not =
implementation specific.  Furthermore, these methods are identical in =
purpose to CWnd documented methods of the same name.

Assuming that documentation accidentally left them out, I think there is =
a problem:

Temporary objects that are created from handles are stored in maps and =
deleted during application idle time (there are other times, but it's =
not relevant).  Or if you like, each class has a DeleteTempMap for you =
to do it proactively. =20

The global function that frees the temporary maps is AfxUnlockTempMaps =
(found in WINHAND.CPP).  Among other things, it eventually calls each =
class' static DeleteTempMap method.  Only a few MFC classes will create =
temporary objects, namely CWnd, CGdiObject, CDC, CMenu, and CImageList.  =
But AfxUnlockTempMaps doesn't call the static CImageList::DeleteTempMap. =
=20

So unless I'm mistaken, if you create temporary CImageList objects, they =
will slowly consume memory as your app runs.

(On a similar note, why is CAsyncSocket::FromHandle not called =
CAsyncSocket::FromHandlePermanent?  Since CAsyncSocket won't create a =
temporary object, using FromHandle is misleading, especially when the =
identical functionality is called FromHandlePermanent in other classes). =


- Joseph

---

| Вернуться в корень Архива |