Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

How to check if the released object reference is the last one?

Status
Not open for further replies.

foxdbs

Programmer
Aug 5, 2004
66
CZ
I need to know, before I will assign NULL into a variable, if this is a last reference to the object.
In other words - if I assign
oObj = NULL
if this will release oObj (with running of Destroy) or not (i.e. object has other references to itselves and it will continue work).

If I could have such information, I would like to call some method earlier (to remove all references to other objects inside the object going to release).
 
if this is a last reference to the object
If You create object by:
oObj=Newobject(...
or
oObj=Createobj(...
you will have the only hash as reference to this
object.
When you release this hash you release object in real.

Try it in Debugger...


Juri Shutenko
Municipality of Maardu, Estonia
 
if this is a last reference to the object
If You create object by:
oObj=Newobject(...
or
oObj=Createobj(...
you will have the only hash as reference to this
object.
When you release this hash you release object in real.

Try it in Debbuger...


Juri Shutenko
Municipality of Maardu, Estonia
 
If I make following:

oo1 = NEWOBJECT(..)
oo2 = m.oo1

and then I set

oo1 = NULL

the object remains exist.

When I set later

oo2 = NULL

then Destroy() fires and object disappears. And I need to know just before that last command, that this assigning will realy release the object (because I need to do something with that object immediately before I release it).
 
I have more objects, each uses services of other objects. So it need to have a reference to objects, which it will use. I don't want use public variables, so I give the references to other objects as parameter for the Init method and the object save them into its properties.

All works fine, but if I release the main application object with oApp=NULL command, then I see that Destroy method will not fire and object stays in memory. It releases with CLEAR ALL or with FoxPro exit - and I think this is not very good.

I know, that I can release (set to NULL) all references in all properties of all objects manually, but I prefer to write a recursive method, f.e. ReleaseMe(), which I can call and which releases all references inside the object going to release.

But here is difference: If object is created with NEWOBJECT command directly into the property, I can call my ReleaseMe() method recursively.

But if I have assigned a previously existing object into a property, and I call ReleaseMe() for it, then, maybe, such object shell continue live and it is not good idea assign NULL into its properties.
 
Hello foxdbs,

But if I have assigned a previously existing object into a property, and I call ReleaseMe() for it, then, maybe, such object shell continue live and it is not good idea assign NULL into its properties.

Why isn't that good? If you assign NULL to such a reference that was given by parameter and stored in a property you are not really destroying the object, if there are other references, as you observed yourself.

On the other hand I'd only set such a property to NULL to clean up everything, in the knowledge that the object to which this NULL set property belongs will not again access this property and/or be released itself soon. And if this is done subsequently, you wouldn't have problems with finally releasing oApp.

That oApp cannot be properly released at the end is a problem. But I think solving it with such a forcing recursive reference killing method is not a good solution. You should find out where and what references remain and where you didn't release something properly.

As a reference is a reference to another object and you can't easily determine from where some reference points to THIS, it's hard to do. Well, many classes have an Objects-Array (or rather a collection), but you'd have to recursively search all of these and some classes have Addproperty() but no Objects property, so you may not be able to extract all needed informations and find all references.

A good strategy may be to have mediators, that are objects who know about other objects and how to handle them. Then for example a form calling a child form wouldn't pass THISFORM to the child form, but a reference to a mediator object, which has a reference to THISFORM. Then the childform would talk to the mediator, if it want's to do or know something of or from the parent form and the mediator would talk to the appropriate form. The mediator is mainly decoupling. Forms "log" in and out of such a mediator object, that thereby knows which references are or are not needed anymore, if releasing is allowed or if some depending objects or forms are not finished yet. Think of it as an intelligent reference in both directions. That may also decouple "sister" objects and thereby decouple objects n:m relations.

Bye, Olaf.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top