>>I haven't had any bad experiences, so that isn't the reason. The reason I don't use an assign method with properties that are reference holders for objects is that: 1.) I use a very strict methodology in determining what a defined property is used for. IOW, if a property is intended to hold an object, it's an object and initially set to NULL. 2.) No where in the VFP docs does it reference that _assign can be used with objects, only properties.
>
>What is IOW? Is there a link somewhere to these types of acronyms?

"In other words". I believe that you can expand the acronyms in your account set-up. There used to be a page with them. You might find it via the help icon.

>First can we agree that the property isn't really an object rather a reference to an object? If not this really needs to clarified.

Sure, I don't have a problem with that.

>Second I thought we had a common understanding that there is a place in VFP documentation that says that _Assign methods are meant to be used with reference members. Message ID: 895271 (I'd create a link to this message but I don't know how)

I mostly see that it references properties, but I wouldn't argue about reference members.

I haven't looked at MESSAGE#895271 yet. (That's for both of us< bg >).

>>The problems that Fabio has unconvered, in my mind, confirm that this is an appropriate choice.
>
>With the problems that we all have discussed in the last few weeks, I'd have to say there needs to be some consistency in how _assign method works with reference members and the object. Once this can be clarified I can see _assign method with objects being a pretty powerful tool.

I've used it alot myself, it makes validation very easy (and it works with SCATTER...NAME and GATHER...NAME).

>>I'm asking what is purpose of having an _Assign event to an object. The problems seem to be related to skipping the assignment of the property to an object. The only thing I can gather from the code I've seen is that he's trying to keep the reference from being overwritten.
>
>Point taken. Maybe one could quailify their intent before posting. I'm looking for a solution, or I'm trying to understand the behavior? Heck I don't know.
>
>>If this is the case, then there's a very simple, and in my mind, more appropriate way to do this. Simply make the property protected or hidden, and create an interface to it for the assignment. It takes only one additional statement (the PROTECTED/HIDDEN keyword). The same code that would be in the assign event can be used in the interface routine. The only change in assigning the value would be to call the method. Finally, the problems that Fabio has unconvered go away.
>
>I'm sure this would work, but wouldn't make it harder to maintain? Isn't that what access and assign method are for, allow object members to police them selves? Anyway these are design issues that one could discuss forever.

No harder to maintain, I don't think, but I see where it might cause some insignificant problems. It's a good practice to hide the details of how something works. You only have to worry about the interface and the acceptable parameters. By hiding the details you make things simpler and easier to understand and maintain. As long as the interface doesn't change, the internals can be changed at will without having to make any changes to any external calls.