Hi George,

I have, with my limited knowledge of C++, tried to follow this thread, and I must say that I have come to the same conclusion as you. Using commands and functions to things they are not meant for, is like playing Russian Roulette. If it did not go off the last time, does not mean that it will not go off the next time. <vbg>

>Walter,
>>
>>>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.
>
>There's always room for other interpretations. If you close your mind and at the same time take the first hypothesis that comes to mind and immediately rule out all others, it's a mistake.
>
>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.
>
>>>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.
>
>Ah, but you're getting the additional call to the assign method.
>
>>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.
>
>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.
>
>>>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.
>
>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.
>
>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?
>
>Rather than wasting the time of the Fox Team in researching this, the answer to this problem should be simple, "Don't do that!"
>
>>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.
>
>>>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:
>
>Yes, I certainly do understand the difference. That was my point. If I made it poorly, that's my fault.
>
>>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.
>
>Nope, it isn't. Sorry if we disagree.
>
>>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.
>
>There is no bug here.
>
>>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.
>
>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.