Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Destroy fires twice
Message
From
22/02/2010 15:14:05
 
General information
Forum:
Visual FoxPro
Category:
Classes - VCX
Environment versions
Visual FoxPro:
VFP 7 SP1
OS:
Windows XP SP2
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01450229
Message ID:
01450329
Views:
97
>>I really don't see the difference. Both methods will destroy the object. The problem is VFP sometimes does not clean up all the objects in a complex class that holds a number of objects. In my experience, it is not consistent but it happens. All my cleanup problems went away when I started cleaning up before releasing.
>>
>
>Main_ Job2 is not supposed to call a Destroy of the object. If it's called from Main_Job2() then something is wrong.

That was indeed my fault, as I admitted here: #1450252

Makes the titel of this thread a complete misnomer. :-)

What remains is the screwed up memory. :(

>>>I haven't tried, but would it be the same behavior if instead of first poLog = NULL you'll use
>>>poLog = createobject('empty')
>>>
>>>>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?
Groet,
Peter de Valença

Constructive frustration is the breeding ground of genius.
If there’s no willingness to moderate for the sake of good debate, then I have no willingness to debate at all.
Let's develop superb standards that will end the holy wars.
"There are three types of people: Alphas and Betas", said the beta decisively.
If you find this message rude or offensive or stupid, please take a step away from the keyboard and try to think calmly about an eventual a possible alternative explanation of my message.
Previous
Reply
Map
View

Click here to load this message in the networking platform