James,

The screwed up memory is real, but additional debugging showed that I have misinformed you all here. The first firing Destroy() is actually the destroy of another instance, in a deeper layer. The object variable was burried in a private array that is declared in main_job2 and passed over from routine to routine. Each routine is able to either use the existing object or create its own and pass that one to the next routines. And that array finally gets out of scope on return from main_job2.

Remains the fact of the memory leak.

Your suggestion is okay under normal circumstances. However, in this case I want an escape route anywhere, by calling RETURN TO main_job. And that's only possible if the cleanup is done by the Destroy, because that one will always fire.

Oh well, I WILL find a workaround, even if it takes the whole evening, and night, and tomorrow, and .... :-)


>Peter,
>
>I don't know if this behavior has been identified as a bug or not, but I have made it a practice for several years to call a cleanup method for each object before the destroy fires. I also see that version 5.0 of webconnect has a dispose method in all the classes that gets called before releasing the object. I saw a post by rick where he said that VFP sometimes doesn't clean up very well and that is why he did that.
>
>>Here's the overall structure of a program:
>>
>>

PROC main_job
>>private poLog
>>poLog = NULL
>>main_job2()
>>poLog = NULL                     && <== here the Destroy() fires again
>>RETURN
>>
>>PROC main_job2
>>     poLog = someobject()
>>     RETURN                     && <== here the Destroy() fires first
>>

>>
>>The object has cleanup code in its Destroy(). I'd expect the Destroy() to fire where I set poLog to NULL again. However, it also appears to fire on the RETURN of main_job2. Why?
>>
>>But there's a far more serious problem. Within the second Destroy() the internal memory space of VFP gets screwed up totally, ruining certain variables. This happens on the line of code where variables are declared LOCAL (in the Destroy Event).
>>
>>Anyone here familiar with this quirck/bug? Is it my misunderstanding of some concept?