Garbage collection for PB?

[Edwin Knoppert]

For my xll (Excel addin) i would like to invent a new way to claim memory and destroy it right after the call.

When Excel calls my function, i can not destroy the returned string.
Using a STATIC is an option but not threadsafe.
Using arrays holding memory pointers is an option, i am looking for something different so i tried this (not working):

Class Class1

    Class Method Destroy
        MsgBox "END"
    End Method

    Interface Interface1: Inherit IUnknown
        Property Get Value() As String
            Property = "1234"
        End Property
    End Interface

End Class

Function Test() As String
    Local oInterface1 As Interface1
    oInterface1 = Class "Class1"
    Function = oInterface1.Value()
End Function

' Execute
MsgBox Test()

Unf. the msgbox END is executed before getting the "1234"

Maybe you have an idea similar to this and handy to use?

[Michael Mattias]

>Local oInterface1 As Interface1

Per doc (hard to fnd), any LOCAL "as <interface>" variables are automatically cleaned up when exiting the function. (ie LET varname=NOTHING is done for you).

What is it you want to explicitly destroy or not destroy? The string (property value)?

[Edwin Knoppert]

Of course this example is wrong but i would like to destroy after the caller has obtained the data (Excel).

You could use a timer enuming com interfaces and check a status flag for example.

Looking for something clever with a similar approach.

[Dominic Mitchell]

Because the callee(your object) is returning a string, what is wrong with conforming to the
rules of COM by having your object allocate the string using SysAllocString. The caller is
responsible for freeing a string returned via an out parameter using SysFreeString.

[Edwin Knoppert]

I know but there are exceptions, like Excel/xll
Unless i am very wrong here.

[Michael Mattias]

Maybe you could/should ask in an MS-Excel user or developer group? Those folks would have to know about doing this kind of stuff specifically with MS-Excel.

MCM

[Edwin Knoppert]

Yes, of course.