Sorry about that. I should have made the example a little clearer. The leak only exists if you are returning a string from the VFP COM object.

Try it.


>Michael,
>
>That's a rather odd test you are doing there, having VFP create 64k strings in it's address space and then never do anything with the result. Perhaps you can design an alternate memory buffer space technique.
>
>FWIW, I have a VFP5 COM server sitting in a plant doing data access, it runs 24/7 for months without shutdown. The server methods get called on the order of 10 times a second. We don't see any memory leaks. The server methods return an 32 bit integer to the VC++ code that calls it.
>
>>Try this one out. It contains the COM object and test code. Compile the PRG code in a VFP project. Call the project Rettest
>>
>>I have found this really nasty memory leak when returning a value from a VFP COM object. Every call to the object causes memory to leak!
>>The size of the link varies between VFP 5.0 and 6.0. Under 5.0 it is about 100K per call to the COM object, under 6.0 its about 10K.
>>
>>Microsoft's response is that it the bug exists and they will NOT fix it in VFP 5.0. "MAYBE" it will be fixed in 6.0! I thought COM was the future. Microsoft is not taking it to seriously.
>>
>>Let me know what you find out.
>>
>>Thanks
>>
>>*************** RETTEST.PRG
>>* Create a project called rettest
>>* Use this PRG file to test also
>>* Used NT Task manager to watch memory
>>*
>> public mobj, idx
>>
>> mobj = CreateObject( "Rettest.ObjectTest" )
>>
>> for idx = 1 to 10
>> mobj.MyGetObject()
>> Wait "Hit a key"
>> next idx
>>
>> mobj = null
>>
>>
>>Define Class ObjectTest as custom OLEPUBLIC
>>
>> Function MyGetObject()
>>
>> return Replicate( "D", 65000 )
>>
>> endfunc
>>
>>enddefine