George,

>Have you actually QEDed (quod erat demonstratum)? I'm not so sure.

There is no room for any other interpretation. The number of clicks for release is linear to the number of references to that object (in fact Refcount+1) in my example, that I've got proven. That leaves virtually no other room for any other conclusion that it is a refcount problem.

>When I replace the code posted with This.MyObject = NEWOBJECT("Label") I don't see the same thing from the call stack. However, in both cases I see a duplicate call to the _assign method.

You insist to discuss this matter under your conditions in stead of using fabios example. O.K. Lets discuss your example. When I replace the THISFORM.MyObject = NEWOBJECT("label"), I've create a very different program that Fabio was demonstrating. In your case you create new objects all the time while in Fabios example an object reference to an existing object was used.

Anyways, looking at your example, the click indeed fires the assign event two times. The first one with a .NULL. value, the second one with the actual object reference. This behaviour seem not to occur when the property is .NULL. in the first place. What you're seeing might actually something by design meant to ensure that an object was released when the object is not referenced anymore, just to prevent the problem we've been observing in the reference count.

The fact is that in your example the refcount problem does not exist and does not create a C5, so what you're seeing here might be insteresting in learning more about how VFP handles certain things (whether correct or not), and might give you some feedback, but does not directly relate to the problem here. In Fabios example your described observation does not occur and thus is not applicable to this bug. So I really don't understand why you keep hammering on this.

>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.

>Point: If you have a property that is not an object (IOW, a string, numeric, date, logical etc.), this type of behavior doesn't occur.

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.
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's my contention that objects were never intended to have _assign statements attached to them. It's my belief that, if there's an error involved here, it's a documentation error telling us: "Don't do that".

You really don't understand the difference between a property referencing an object and an objectj contained within another object (e.g. a form), do you? If you do, you certainly have a problem in getting your terminology right:

It's my contention that objects were never intended to have _assign statements attached to them
Objects don't have an _assign event, simply because you can't assign anything to another object. IOW you can't do:

THISFORM.AddObject("MyLabel","Label")
THISFORM.MyLabel = CREATEOBJECT("Line")

But you can assign something to a property or variable.

THISFORM.AddProperty("MyLabel",CREATEOBJECT("Label"))
THISFORM.MyLabel = CREATEOBJECT("Line")

In the first case THISFORM.MyLabel is an object. The second case a property containing an object reference. You cannot assign a newobect to any other object, so a THIS_ASSIGN event does not apply since such event can never occur. The closest thing you've got is the INIT event of such object. In the second case you can assign anything to THISFORM.MyLabel since it is just a property. Whether it contains a single value or an object reference does not matter. Here the Assign and Access events do apply, because a property can change.

As for your believe it is a documentation error: Any piece of native VFP code that internally (Within VFP, Not external drivers, API etc) creates a C5, is a BUG. a Highlevel language should prevent that. Also, if some object releases without beeing forced to release via a the container beeing released, an explicit release or having no references left to the object, is a bug. You can try to distract me in any kind of exotic example or refer to some documentation; it does not matter IT IS A BUG.

Given your resistance to accept the facts in the bug beeing caused by a reference count problem, and you're appearantly beeing to proud to see that you were wrong, I see no point in discussing this issue much further. Fabio and I, (and sergey to some extent) have tried to talk some sence into to you, but it seems like talking to a wall here. You seem not willing to accept a lesson from the persons involved in this thread.

All I can say that I find this a really, really sad situation for a person with such involvement in the UT and feel sorry for it.

Walter,