How? ...not to have them in the first place. :)

I have a container class which is used for some service purposes.
It may be visible or invisible, depending on the purpose. This container supposed to hold the references to other objects in it's properties. During the testing, when those references were not NULLed by various reasons, I got an idea not to have them "alive" at all - i.e. object property refers to the object only when the container method needs it.

To simpify this sample let's say the container has just one object to handle, so we are not passing any parameters to it's methods.

Now, instead of assigning the object to the property directly, say:

myContainer.oObject1 = myObject

I have two properties:
.cObject1
and
.oObject1

and two methods:
.set_oObject()
and
.release_oObject()

Say,
.cObject1 = "thisform.myPageFrame.Page1.cntMyContainer.cusMyCoolObject"
oObject1 = .NULL.

*** .set_oObject() method code
LOCAL llReturn
WITH this
	IF !EMPTY(.cObject1)
		LOCAL lcObject1
		lcObject1 = .cObject1 
		*** put the check here for the object existence.
		.oObject1 = EVAL(lcObject1)
		llReturn = .t.
	ELSE
		IF .lWarnIfEmpty 
			??CHR(7)
			WAIT WINDOW this.name + ".cObject1 is not specified" NOWAIT TIME 2
		ENDIF
		llReturn = .f.
	ENDIF
ENDWITH
RETURN llReturn
***

*** .release_oObject() method code
this.oObject1 = .NULL.
***

Then, in some custom container method which manipulates with the object PEMs:

 **** myContainer.MyMethod()
 WITH this
	 IF .set_oObject()
		 WITH .oObject
			.SomeProperty = somevalue
			.SomeMethod()
			*** more processing here
			.release_oObject()
		 ENDWITH
	 ELSE
	 *** scream here :)			 
	 ENDIF
ENDWITH

So, when myContainer is doing nothing - it does not have any references to the objects, they (references) appear "alive" only when the appropriate method runs.

This version applies to VFP 5, but in VFP 6 we can use _Access() method which can automatically set and release those object properties/variables.

I am not saying it is good in all cases, but now I care about dangling references less... :)

Nick