>>>>>Try to execute them on the separate lines

? myCollection.Remove(-1)
>>>>>? myCollection.Count
>>>>>

>>>>
>>>>Of course,
>>>>as it must be, the result is the same one,
>>>>the collection is not emptied completely.
>>>
>>>It's not always the case when dealing with bugs.
>>
>>This is true, Only that I had tried that code before opening the thread.
>>
>>The point is that every method of the Collection class is not reliable.
>>
>>Ill-fatedly it is difficult replay with a short code,
>>and without a code to analyze I doubt that the VFPT can arrange it.
>
>What do you store in the collection when it happens? Some kind of complex object with references to other objects?

I known this, but i'm sure this is not the issue.

I store a complex dataModel ( 10000 objects ),
with mutual references.
On this, exists only 2 deadlock objects ( now ),
then I must change the solution to that guarantees to me that
VFP releases all the dangling references of an object.

However the collection's issue still open.

When i run:

collection::Remove(-1) && Count is 104
collection::Remove(-1) && Count is 0
* here i have 2 zombi objects ( i use a create/destroy counter )

with little objects I have look 7/0 or 9/0 ...

Then I remove the dangling references ( computed dynamically )
and the behaviour don't change.

> Maybe FoxPro cannor release those objects from collection because of some dangling references or similar?

This is not true, why the removal from the collection is not one destruction of the object,
the destruction it only happens when the semaphore that it holds it alive it becomes zero.

If this depends on the thread that it manages the heap garbage collection,
perhaps this behaviour can be obtained also with collection of big strings.