>>>The difference is that createobject() and newobject functions will create standalone objects, while .addobject() and .newobject() methods of a form or any of its members which have those methods will create a member object in form's containership hierarchy. Member objects have .parent objects, and ultimately up this hierarchy there would be a form which can be referenced as thisform. Unless, of course, your top container object is something else (custom, session etc).
>>
>>Thank you. This is what I did: thisform.NewObject( "myObjectName", "myClass", "ClassLocation.prg"). And my understanding is that since I used the form NewObject() method I don't have to explicitly destroy (set to NULL) the object myObjectName when releasing the form.
>
>The object would lose reference count anyway, i.e. if it was referenced only as a property of your form or one of its objects, it would lose that reference when the form destroys, and would be destroyed automatically. However, depending on what you do on the form, other references may be created and so manually destroying it is a matter of good housekeeping. With a member there's more of a guarantee that it will die with the form.
>
>>I also plan to modify my class (probably today) using the approach described by Tamar where the parent form will be passed to the class. Instead of referencing the form (thisform) in the class method.
>
>Depending on what you may do with this class in the future this may really be wise. It may be usable for other things, so at some point you may pass other objects as parameters, not necessarily forms.

You could abstract such call/communication options into a "broker" object - personally I find implementing such brokers as wrapper objects easier to visualize along containership "lineage"when brooding over design without a screen (aka long drives...) compared to "plugin-adapters" where different endpoints are renamed into a logical structure or method interface...