>>>>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.
>>
>
>The above term 'member' is kind of confusing to me. The way I instantiate the class into the object (my code above), is the object a member of the form? And what would be a example of a non-member of the form?

From the form or any other parent object of an object, or of a referenced (non-member) object, there's no difference. You can call this object's code and reference its properties just the same.

However, a non-member object, i.e. something added by this.addproperty("oObjName", createobject("someClass")) doesn't have a .parent (it's either null or errors out if you try to use it, don't remember, it's been years since I last tried) and thisform just doesn't work. With member objects, ie. those added in the designer, or via .addobject() or .newobject() methods, .parent is the caller, and if there's a form up the parenthood hierarchy, thisform references it.

Which is better? Yes and no. It's sometimes good that you can't reference upstairs, or you can get into a habit of writing fugly code like xx=this.parent.parent.parent.pgf.page4.cnt2.DoSomething(), which I've seen a lot in visual classes. That can break in a dozen interesting ways. OTOH, it's quite common to have in cmdSomething.click() a call to ThisForm.DoTheThing() - which is actually recommended. That actually breaks encapsulation in a way, but in a very limited way - yes, you can have direct calls from a member to a form-level method. But if you see .parent.parent somewhere, it's perhaps time to rethink the design.

It's more or less a step in the pursuit of an answer to the prime question of OOP - where does the code go?