How can I discard all the current objects?

[Agustin Tristan-Lopez]

My program has deleteobject, freelibrary, and so on. Nevertheless there is a moment when the program fails due to lack of memory or resources available. If I use the "resource meter" from the "windows accesories" I can see how some parts of the program reduces the available amount of resources, specially the GDI.
How can I know exactly the object that is actually producing the problem? Is there a function available for that? Is there a way to discard ALL the objects that I don't need? I mean ALL because I can do selective deleteobject, but I cannot find the object that is occupying resources.
I looked at Petzold (Windows 95) and Appleman (VB Windows API32), but excepting deleteobject, freelibrary, deleteDC, and so on, I cannot see how to solve the problem.
Best regards.
Agustin

[Lance Edmonds]

GDI objects are technically "owned" by the GDI. Automatically releasing all [GDI] objects created by your application is only possible when your process ends normally - the only other way to release all the objects is to explicitly release each one individually...

This is obvoiusly not a pretty task, unless you have carefully designed your app to cater for this in the first place... retrofitting clean-up code is much harder than doing it right in the first place.

Ok, the sermon end here.

So how do you solve the problem? Use a resource checking tool to examine and log your application's creation and release of GDI objects.

The first technique (and the cheapest) is to write an entry to a log file each time a GDI object is created, and again when it is destroyed. By examining the log, you should be able to identify any objects that are not being released.

This technique works, but is time consuming - writing small wrapper functions to write the log at the same time as the object is created is a possible solution to ease the burdon.

Another potential place for problems is failing to check the return value of DeleteObject() - it may be failing due to a wrong handle being specified, but unless you check the return value, you'll have a very hard to find bug right under your nose.

Another common problem is the brush objects used for %WM_CTLCOLORxxx handlers - your code is responsible to destroy these objects, so any objects (like brushes) that are used in these message handlers must have the object handle stored in a STATIC or GLOBAL variable so the object can be release during
%WM_DESTROY.

A much easier and better way to check your code is to use a commercial tool such as BoundsChecker or MemCheck - this is a VERY expensive route though - these tools are about US$300 or more each, and you stil have to work out where exactly the problem is stemming from - it can be much easier than manually debugging the code as I suggested above.

I personally use MemCheck 5.0 from http://www.stratosware.com - they may still offer a 14-day trial edition for you to try out - at least they used to.

It is a very powerful tool, but it flags all sorts of errors that are not "real". The key is to get to know what errors is detects are the ones you need to work on in your code. The errors you can ignore relate to releasing global memory that thePB/DLL allocates for GLOBAL variables - these are released by Windows at app termination, but because the code does not explicitly release them, MemCheck is quick to tell you.

Typically, any GDI related error will be correctly flagged by MemCheck, such as failing to release an object, or using an invalid handle, etc.

It includes a useful API, and I use the mc_Debug() to add notes into the debug error log - that way I can add calls to my code to narrow down the point where the problems are originating. When your app ends, MemCheck will signal all GDI that have not been released.

If you search this BBS for "memcheck", you should find additional information that may be helpful to you when you come to using this tool.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Agustin Tristan-Lopez]

Hello Lance:
As always your answer is not only complete, but very wise. I shall try what you suggest, I think the log will be very simple to use in my case, according to the routines I'm actually developing.
Thank you again.
Agustin


------------------

[Patrice Terrier]

Salut, content de te voir à nouveau sur le forum PowerBASIC.
Que deviens-tu? (J'ai perdu ton email)

Hi, nice to see you again on the PowerBASIC forum.
What are you doing now? (I lost your email)




------------------
Patrice Terrier
mailto[email protected][email protected]</A>