Walter,
>
>>First, the "m." convention. I'm perfectly aware of "EssentialMDot" on the FoxWiki page. I'm sure that you'll agree that any convention has to have a purpose. Without such, it is meaningless.
>
>>From reading Fabio's posts, it appears that he believes that using "m.This" or "m.ThisForm" is faster than it would be without the "m.". Is this really the case? See THREAD#895232. If it isn't then the convention is pointless. Further, because it may lead to a C5 error, why use it?
>
>Fabio has listed a sample today in which it was showed. I Did not dive into the details, but I believe he was correct. Also in another thread it was proven that the C5 seems not to be directly related to the m., so that bit has not been proven also.

I'm not so certain that Fabio's post is correct, if we're speaking about his response to me. I'm about to respond to that in a few minutes.

Well, given that removing it helps to elimanate some C5s, it's reason enough.

>I think the fact that choosing one strategy over another should not have anything to do with BUGs. At one time the first strategy could show more serious bug and the next version could show the other way arround. There is only one possible solution: Report the BUG, workarround it and pray to VFPT to solve it.

Is it a bug if we misuse the tool in a manner that wasn't consistent with the design? Or is it a documentation omission?

>>Second, on more than one occasion you've questioned whether I understand the difference between a property and an object. I most certain do, but wonder if the same holds true for you.
>
>>When we assign a property an object, it is no longer a property, but rather an object.
>
>This I think is the matter. This is not true. The property remains a property no matter what type of value is assigned to it. If an object reference is assigned to it, it still is a property. The same applies to variables a variable is a variable whether it contains a simple value or an object reference.

Walter, one of the key things about computing is that a great deal depends on how we define things. For example, a bit of a byte is either opened or closed (set or cleared). There is no middle ground, no indeterminate state in any situation. It is either a property or an object, not both. I choose to think of it as an object.

We can go back and forth on this, but it's really rather pointless.

>Some things to consider.
>
>1. An object reference assigned to a property can be removed by storing something else in it. An object can only be remove from a container with a RemoveObject call. Using your analogy, if I have a property on my form containing an object reference, it becomes an object. Then I should be able to remove that object with removeobject(), which is not the case.

This would be a bad practice, IMV. Everything should have a specific purpose. IOW, re-using something that was originally intended for another purpose is a mistake.

>2. An object reference by a property does not recieve any events the form containing the propery. Neither can the object be a visual part of the form.

So???

>3. An object can only be contained by one container. Its reference is stored in the parent Property. Referencing an Object through a propery is giving you the object in which the object is contained, which can be another form or container, very differently from the properties parent.

Yes, and in the original message it was being stored in two places.

>4. An object can be referenced by many properties. So if I've got one object and I reference that object through 20 different properties, are you saying that we've got 20 objects now ? No this is not correct, we've got one and the same object, referenced by 20 properties. If I release the form containing the object, all refering properties are set to .NULL. However If I release one property nothing the object is only referenced by 19 properties and notheing else changes.

No this is not what I'm saying.

>5. When I reference an object through an property on a form and I release the form, I only release the reference to that object, which might not be released (depending if there are other references to it). If an object is part of the form and the form is released, the object is released as well.

This is why we should our own internal housekeeping. To assure that there are no dangling object references.