We ran into this with our business objects in VFE ten years ago and decided it was best practice for any object instantiated within the scope of the business object to call its destroy() and then set its object reference to null before calling the destroy() of the containing object.
This seems to have taken care of the issue for us.
>Here's the overall structure of a program:
>
>
PROC main_job
>private poLog
>poLog = NULL
>main_job2()
>poLog = NULL
>RETURN
>
>PROC main_job2
> poLog = someobject()
> RETURN
>
>
>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?
Charles Hankey
Though a good deal is too strange to be believed, nothing is too strange to have happened.
- Thomas Hardy
Half the harm that is done in this world is due to people who want to feel important. They don't mean to do harm-- but the harm does not interest them. Or they do not see it, or they justify it because they are absorbed in the endless struggle to think well of themselves.
-- T. S. Eliot
Democracy is two wolves and a sheep voting on what to have for lunch.
Liberty is a well-armed sheep contesting the vote.
- Ben Franklin
Pardon him, Theodotus. He is a barbarian, and thinks that the customs of his tribe and island are the laws of nature.
