>>I don't know if it is a bug or not. I don't know if that is the cause of your problem or not.
>>
>>I am not suggesting that you merge the classes. You said this app is running for awhile and it creates and destroys objects. My suggestion is to create the objects once and leave them created. Then use them over an over and don't destroy them until you are done and the app is quiting to the desktop.
>
>Unfortunately with my current design,I have to create and destroy these objects. I cannot reuse them as you say. I can try to explain a little by what I mean.
>
>I designed four classes to act as a wrapper for the Lotus Organizer API. The ultimate goal of the program is to access records in the Organizer calendar. With the API, you start a session, then open an Organizer file, then open a section within the file, and finally access records within the section. Each of these steps returns an Integer handle.
>
>For the program to receive current information, the record, section, and file handles have to be closed and reopened. My program displays a calendar on a monitor so it needs to display changes as they occur. Another twist to the program is that a different calendar displays each day. A section contains one calendar. So, I have to close the record, section, and file handles each day.
>
>So, I thought the best design was to have four classes: session, file, section, and record. Each class has a handle as a protected property. Upon creation of the object, it would open, and upon destruction, it would close.
>
>Now it looks like I need one object that stays around until the application dies. This object would have four protected properties for each handle, and an open and close method for each Organizer type. If this approach causes my resources to dwindle, then I guess the Organizer API is the culprit.
>
>So what do you think?


Isn't there a low-level call that you can make via the API that compacts the heap?

On a side note, I sent an e-mail to the developers of HeapWalker (their name escapes me now). They make a third-party memory management library that you can use in place of Microsoft's memory management in Visual C / C++. I asked them if they knew a way to hook it into VFP 3.0 and 5.0, since I was aware that VFP 3.0 used MFC 2.0 code (not necessarily known for memory management efficiency), and VFP 5.0 uses MFC 4.0 (haven't work with that set of classes, so I don't know how much better it is than 2.0).

Anyway, I haven't heard back from them, so I'm uncertain if it is possible or not. If there are any brave, determined, (desperate?) souls out there that will (or have?) tried this, I would like to hear the results.

Ed