George,


>I did say “two problems”. The first, and most obvious is the C5 error that occurs not only in this case, but also in another of Fabio’s posts. In both instances, the problem is easily resolvable. He insists on using the “mdot” prefix when referencing an existing object. When the “mdot” is eliminated so is the C5 error.

Whether a BUG is easy to workarround or not, it still is a BUG. You'll have to be aware of this bug to know the workarround. For all the people that don't know this bug, it could mean they spend significant amounts of time to find the cause of their C5. Therefore, My opinion is that every BUG that is generating C5 should be eliminated.

>The question here, therefore, is it appropriate to use this notation in this and similar cases? The first thing that comes to mind is that an object reference such as “This” or “ThisForm” isn’t a memory variable, it’s an object reference. My opinion is that using the notation is neither necessary nor appropriate, especially if it is the cause of a C5 error and not using it eliminates it.

There are some people advocating the use of mdot, and they want to use the m. notation. Since it works normally in about all cases, it is somthing that is allowed in VFP. It generates a C5 in this particular case and therefor should be solved.

>The second problem is creating an _assign event for a property that’s intended to hold an object reference. Nowhere in the documentation is this event referred to in a context other than a property. An object reference is not a property. A property may hold an object reference, but that does not mean that it can have an _assign event.

Please, please, please get your terminology right, because you're causing quite a bit confusion up here. A property is a variable bound to an object. A variable could contains a single value of some simple type or object reference.

Nowhere in the documentation is this event referred to in a context other than a property
And? Isn't that exactly what Fabio is doing? He creates an assign event on a property. That the property in his case might contain an object reference does not change it one bit.

Your remark "An object reference is not a property" is a nonsense one because an object reference is a value, and a property is a type of variable that can store a value. So a property can contain an object reference.

A property may hold an object reference, but that does not mean that it can have an _assign event

A property can have an assign event, no matter what the type of its value is. Let me remember you that one (and AFAIK the only) way of ensuring a custom property is of a certain type is using the _assign event. The assign events is bound to the property and not to the value or object reference it contains.

>Finally, I had no intention of being insulting by implicating that Fabio was misusing the tool. Do I believe he is? Yes! This simply my opinion, and I’m entitled to it, just as he is to his and you are to yours.

Despite the fact that I disagree, If it was clear that it was your opinion than it would not hurt that much, but if using the authority to state it as fact OTOH is.

George, I do believe, despite your efforts to show otherwise, you don't know the difference between an object and a object reference and also don't understand the difference between a member and a property. Your posts in this thread show so many statments about properties and object references that do not make sence at all, so I cannot conclude otherwise. This is the whole cause of the confusion. Until you show to have understanding of this, this discussion is useless.

I'd recommend you to have a more open mind for what someone is telling ISO taking a stance at the first sentence containing the word "BUG" (In fact this is what you're accusing us for) and reread the thread again.

Walter,