>Hi Naomi,
>
>>Do you think it's worth the trouble to make a generic Destroy method or it's better to continue the current practice of modifying each individual form's Destroy method?
>
>You need generic code in the base classes, but there are some issues...
>
>- It's not sufficient to remove all references within a form, you also need to clear all references in outside objects that point to objects on your form. For instance, you might have some global error validation object that keeps a reference to the control that caused the error. The rule is: There must not be any reference to any object on a form.
>

Hi Christof,

AFAIK the objects don't point to the objects on the form. However, here is what I have:

Programmatically defined custom oBill class. In this class we have in the Init

	WITH THIS
		.oFile = NEWOBJECT('CFile', 'c_file.prg')
		.oTabBill = NEWOBJECT('CTabBill', 'c_tab.prg')
		.oTabProject = NEWOBJECT('CTabProject', 'c_tab.prg')
		.oTabIndent = NEWOBJECT('CTabIndent', 'c_tab.prg')
		.oSettings = NEWOBJECT('CSettings', 'c_settings.prg')
	ENDWITH

And in some method of the class we have

DIMENSION .Details[.DetailCount]
			FOR i = 1 TO .DetailCount
				.Details[m.i] = NEWOBJECT('CBillDet', 'c_billdet.prg')
				.Details[m.i].GetRec(laResults[i, 2])
........

where cBillDet class has another class as a reference.

In the form we have oBill object property.

Now, what should I do with all of these references and how can I properly release them?


>- Destroy is usually too late. It's much better than not doing anything at all, but you still might see crashes. The only stable solution is in my experience to clean references in the Release method before you issue DODEFAULT() and in the QueryUnload event when you allow unloading.
>

It's a bit unclear. Would it be enough in Form's Release method instead of the form's Destroy?

>- Generic clean up code is difficult to do with arrays and collections. With arrays you only need to check looooots of elements. With collections you can have overridden access routines that don't allow numeric index access anymore.
>
>- Before you attempt to access an o-property, you should check for a access method. Such properties might not store a property, but request objects from somewhere else. The same is true for assign methods.
>
>- If you use classes from other developers make sure that your code can deal with varying visibilities, especially with hidden properties. Also, they might not use the same naming convention. So you might miss object references in this case.
>
>- Check for ActiveX controls. They behave differently than other controls.

Ok, so how would you suggest me to proceed? I don't like having dangling references, but I'm not sure how to approach the problem.

The applications were written by another developer, who was extremelly productive and loved to use classes for tables, biz objects, etc.

The concept is good, but I'm now having a hard time to follow the logic and checking various places...