George,

>Here (and, yes, I've read the posting of a message from Micrsoft) there's a question: Is the refcount causing the additional call to the assign event, or is it a problem with the call stack affecting this? I don't know, but will happily concede that one way or another the reference count is involved.

Again the callstack does not have anything to do with this. The call stack in all circumstances seem to be fine. I did not see any clue that made me conclude it was a call stack problem. The assign metod was called twice, yes, but this probably intential the release the current refered object if neccesary. However this fact alone is not something you could call a call stack problem (See previous post).

The object beeing mistakenly released is a direct consequence of the refcount beeing zero. Of course there might be underlying problems, but the bug certainly is caused by the refcount primarily. See Microsoft post.

>Ah, but you're getting the additional call to the assign method.

Yes, but that could be explained as a designed behaviour.

>The problem with Fabio's code is that he insists in using "m.This". "This" is not a memory variable and thus shouldn't be preceded by the "m" prefix. Remove that alone from any of his examples and there's no C5.

Remove the m. and the bug still occurs: the refcount is not properly released.

>>>Due to the behavior I am seeing, and due to the documentation I'd have to say that what we're seeing here is the result of the design.

I don´t get it. First you admit it is a bug, now you changed you mind again. Well make up your mind. What is it ?

>>I wish you were more carefull in describing your point:
>>1. A property is NEVER an object. At the most it can be an object reference. There is a big difference between the two.
>
>Ah, here's the crux of the matter. A property can hold an object reference. As such you can place an assign event to the property. With objects, however, you can't place an assign event on the object unless you do it in the manner Fabio has or in the class designer. I said once, "Just because you can, doesn't mean you should."
>
>If I mis-use a tool and do something that it's not intended to do, who's at fault? Me or the manufacturer. Simple, I am.

Mis-use a tool ? Do you know what you´re saying here? The assing event can be used for all datatypes except for object refences. This is not logical, not straightforward, not documented and for the larger part is not true. It only contains u bug (and appearantly is regarded a bug by MS), in a very specific case with object references.

Do you know you directly insult Fabio by saying he mis-uses the tool?

>Since objects aren't intended to have an assign event, how can one complain and say, "This is a bug", when the result isn't what s/he wants it to be?

You really don´t get it yet? Fabio´s example is not using an assign event on an object. You really have trouble in understanding the difference between the assign event of an object and the assign event of a property which might store an object reference. An assign event on an object can never be fired since you never can assign an object to another object. You can only do this with object references (See previous post). The assign event of an object DOES NOT HAVE ANYTHING TO DO WITH THIS BUG.

>Rather than wasting the time of the Fox Team in researching this, the answer to this problem should be simple, "Don't do that!"

So rather in digging this bug out, you want to leave it that people should spend hours and days to figure out what is happening and eventually find out that it is a very difficult to discover BUG in VFP? Good move. At least document it at MSDN as a BUG, then people have more of a chance to find out what it is. But of course much better is to solve this problem for once and for all so that developer don´t have to suffer from this bug. We are not here for the VFPT the VFPT is here for us.

>>2. Your described behaviour is not consistent and does seem to have to do with the release of the previous object reference stored in the object (It does not occur when the propery already is .NULL. and neither if the asigned object is the same as the currently assigned object).
>
>It isn't consistent only in when the second call to the assign event occurs.

Not true. See description above.

>Yes, I certainly do understand the difference. That was my point. If I made it poorly, that's my fault.

This post still contains a lot of statments that proves the opposite.

>I'm perfectly comfortable with my position, Walter, so there's no need to be sad or sorry. Here's the deal:
>
>Object's shouldn't have an _assign event. Do so at your own risk. There's no bug here. This is a mis-use of the product.

Again this isn´t about the assign event on object, but assign events on properties. A total different issue.

Walter,