Locked resources

[netphilou31]

Hi,

I have a dll in which I have put some binary files as resources.
I have defined a particular resource type ("RT_RCDATA") to handle this type of resource.
When I want to access to the resources, I use the FindResourceEx and LoadResource to get a handle to the desired resource, then I use the LockResource function to get a pointer to the resource.
As mentioned in the documentation, it is not necessary to unlock the resource after use but it is recommended to use special functions for accelerator tables, bitmaps, cursor, icon and menu resources (DestroyAcceleratorTable, DeleteObject, DestroyCursor, DestroyIcon and DestroyMenu) but what happen for "special" resources like the one I am using ?
In my dll, the function accessing the resource is called a number of times and I was wondering if there will no memory problems because the resource is not "unlocked" nor "destroyed" before exiting the function.
May I experience some memory leak and how can I be sure that all the memory allocated to the resources is correctly destroyed when the dll is unloaded ?

Best regards,

Phil.

[IanH]

See the comments for LockResource in msdn/the Windows SDK documentation - the memory will be released when you unload the DLL hosting the resources or when your program goes away.  The data associated with the resource will only be loaded once regardless of the number of times that you call the LockResource function. 

In 16 bit windows days there used to be UnlockResource and FreeResource functions or similar, but they are no longer required in the 32 bit world.

Other resource types are different because in addition to the binary data associated with the resource there is also a Windows object, such as an icon, menu, etc, that needs to be created/cleaned up.

[netphilou31]

Hi,

Thanks for the clarification.

I did not read the MSDN/Windows SDK documentation except the one provided withe the Intel compiler. Furthermore, I did not find it very clear about the clean up of the locked resources (except special ones).

Now everything seems to be Ok.

Thanks again Lan

Phil.