CImageList

alex barylski

I remember reading somewhere that WTL does not destroy an object that is attached to it. Does this mean when I attach an HIMAGELIST to a CImageList using Attach() and that CImageList object goes out of scope I have to manually remove or delete the HIMAGELIST or destroy HWND or whatever? The reason I ask I have two CImageList objects inside a class and both get initialized during WM_CREATE. However frequently, one of the CIMageList objects has to be re-created so what I do is Detach() each CImageList object Create image list from system image list Attach() it to CImageList Set the image list to control like Listview In the destructor of my CListCtrl() should I destroy the objects HIMAGELIST? Thanks The word of the day is legs, let's go back to my house and spread the word ;P

Michael Dunn

CImageList is a wrapper around an HIMAGELIST and the image list APIs. The underlying image list object is not destroyed when a CImageList is destructed. --Mike-- Ericahist | CP SearchBar v2.0.2 | Homepage | RightClick-Encrypt | 1ClickPicGrabber "Linux is good. It can do no wrong. It is open source so must be right. It has penguins. I want to eat your brain." -- Paul Watson, Linux Zombie

alex barylski

Thats what I thought, but does this mean then that the HIMAGELIST handle is left floating around? Wouldn't this waste or cause memory leaks of any kind or are these objects destroyed when your application ends? I'm curious basically becuz I have 2 functions, one which initializes an CImageList by attaching it to the system HIMAGELIST returned by SHGetFileinfo, but before attaching I always do a Detach. I figure I would be a bad idea to Destroy() this image list? I do however Detach again in destructor. My second function doesn't use the system image list but rather initializes it with icons I have collected. So I Destroy, then Create and Destroy() again inside destructor. In MFC I've always assumed that destructor took care of everything? :confused: Thanks The word of the day is legs, let's go back to my house and spread the word ;P

Michael Dunn

Hockey wrote: but does this mean then that the HIMAGELIST handle is left floating around? Yes, but... Hockey wrote: Wouldn't this waste or cause memory leaks of any kind or are these objects destroyed when your application ends? No, because when your process exits, all memory and resources it was using go away too (memory gets reclaimed by the OS). However, it's still good practice to not be sloppy, and properly free/destroy/delete resources in your cleanup code. If you want a class that destroys the image list in the destructor, check out this page[^] --Mike-- Ericahist | CP SearchBar v2.0.2 | Homepage | RightClick-Encrypt | 1ClickPicGrabber Pinky, are you pondering what I'm pondering? I think so Brain, but if we shaved our heads, we'd look like weasels!

umeca74

although most WTL classes take care of releasing the object they manage (if they manage it), CImageList is a sore exception. I guess it is not an ideal world! Perhaps it is because imagelists have window semantics and as "windows" you need to destroy them manually To answer your question, yes you should destroy all imagelists you create yourself, ideally at the moment you no longer require them. However the "system" imagelist returned by SHGetFileInfo is a shared resource which you needn't (shouldn't in 9x) destroy most of the other WTL classes have a managed and unmanaged "flavor". E.g. you have CBitmap and CBitmapHandle; the first is managed, destroying the bitmap whenever it goes out of scope, the second is meant for temporary assignments.