Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Destroy fires twice
Message
From
22/02/2010 12:03:55
James Blackburn
Qualty Design Systems, Inc.
Kuna, Idaho, United States
 
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:
01450251
Views:
60
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.

>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?
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform