Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Possible WISH LIST item?
Message
De
25/10/1998 08:33:21
 
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00149579
Message ID:
00150290
Vues:
44
David,

I really *do* appreciate the trouble you have gone to here.
However, I feel you are missing the concept I am trying to get at.

But since you have your mind made up on the issue, I will refrain from further commentary.

Regards,

Jim N

>Jim,
>
>You just don't get one key concept, perhaps it's been lost in all the other text, so all I'm going to go over in this message, snip or throwaway whatever you want, but you haven't made any indication that the point has gotten across.
>
>1) createobject() - this function instantiates an object somewhere in memory. The function returns what? AN OBJECT REFERENCE. A pointer to the real location of the object in memory. VFP6 help states: Use = or STORE to assign a reference to the object to a system variable or array element.
>
>2) you store that reference in a memory variable. THE MEMVAR IS NOT THE OBJECT.
>
>3) if you RELEASE the memvar it goes away, absolutely unequivocally the memvar is gone. Have you bothered to do a DISP MEMO afterwards? If so you'd see that the release did work exactly as it is supposed to. It released a memvar. In fact if you read the VFP6 help on RELEASE the word "object" does not appear in the topic anywhere!
>
>4a) if no other memvar or object property has a reference to the same object, the object disappears too.
>
>4b) if some onther memvar or object property has a reference to the same object the object doesn't go away until all references to it are removed. You are tilting at windmills here if you think you'll convince MS to redesign this fundamental issue. CLEAR ALL is the solution you seek.
>
>Detach yourself from the association you've made between COM servers and VFP objects. I only used the term goServer because I felt most people would grasp the term and why several objects within an app would all want to make use of the services of a single object.
>
>>Have you bothered to read ther VFP 6 (or 5 for that matter) Help for RELEASE, RELEASE ALL the Release method or the Destroy event? It sure looks/sounds like you haven't, because had you done so you would know that the concept of reference counts is *never* mentioned. Furthermore it explicitly states, for all of them, that the thing being released is removed from memory!
>
>
>Just for fun run this program
>
>
clear all
>activate window "debug output"
>
>debugout "main pre createobject " + sys(1016)
>createobject( "cForm" )
>debugout "main post createobject " + sys(1016)
>
>debugout "main pre createobject " + sys(1016)
>x = createobject( "cForm" )
>debugout "main x exists " + sys(1016)
>release x
>debugout "main post release " + sys(1016)
>
>define class cForm as Form
>
>procedure Init
>this.Tag = replicate( "abcde", 100000 )
>this.Visible = .t.
>debugout program() + " " + sys(1016)
>endproc
>
>procedure Destroy
>debugout program() + " " + sys(1016)
>endproc
>
>enddefine
>
>It creates this output:
>
>main pre createobject 334172
>CFORM1.INIT 843296
>CFORM1.DESTROY 843304
>main post createobject 838116
>main pre createobject 838096
>CFORM1.INIT 843904
>main x exists 843892
>CFORM1.DESTROY 843896
>main post release 838112
>

>
>Notice that the first createobject() doesn't store the returned reference, the object was created and immediately self destructs because there is no reference to it. Also notice memory as reported by sys(1016) doesn't decrease after the object destructs. It's also significant that it doesn't double the second time the object is created the allocated memory pool is reused. The memory probably doesn't get taken back from VFP until the OS runs out of memory for another task requests it's freed memory back. This is guess on my part though.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform