FB II Compiler
Seek for a memory leak
A memory leak means:
1) Somewhere in your program you are allocating memory dynamically (NewHandle, NewPtr).
2) Nowhere in your program are you throwing it away.
You can find such a leak simply by doing the same thing over and over and over again, watching the thermometer in "About This Mac". If the bar keeps creeping inexorably upward, you have a leak.
This may not be the problem. Often a "leak" is simply a matter of using various parts of the program, which load up structures they need once - then discovering that there is not enough memory in the program's partition to store everything that's needed. (You can sometimes work around this with temporary memory, which is a nice solution anyway.)
Typically, there are not a huge number of routines that call NewHandle or NewPtr. Memory leaks in this case are a result of not clearly defining whose responsibility the memory is and when it is to be thrown away. In an event-driven programming model, this can sometimes be confusing.
Try writing down a description of which part of your program owns the memory, under what circumstances it is to be created, and under what circumstances it is to be disposed. If you can't clearly define this, then it is a good bet that somehow the memory is leaking away.
GET FIELD, PICTURE OFF, READ FIELD, and the various INDEX$ statements all allocate memory. Check to make sure the handles these routines allocate aren't slipping away unnoticed. Also look for things like grabbing a colour icon with GETCICON, but not throwing it away with DISPOSECICON (A cicon handle in memory is a complex structure with sub-handles; you can dispose of the icon handle itself, but that creates a memory leak.), or similar things with gworlds and such structures.
Automatic memory management is _so_ nice...
You do not need to worry about disposing of resources if you have them marked as purgeable in your project resource file - which _should_ be the case for everything but MENU resources anyway. This is why we always stress that you make a handle purgeable rather than disposing of it yourself. It is always better to let the Memory Manager do what comes natural to it. The Memory Manager after all, has been bug tested a LOT more than your own code has. So let it do it's thing!