This project is read-only.

VFP2C32 - CreateThreadObject - Dangling reference ?!

Topics: Bug Information
Aug 11, 2011 at 5:00 AM

Hi Christian, i have stumbled upon a problem with the CreateThreadObject function and don't know what to make of it.

It seems to me that when i use the CreateThreadObject() function with callback on a form with private datasession, the session doesn't destroys when the form is released.
The only way the forms destroys it's own data session is when i don't make use of the callback feature.

I've tried using as a callback a custom object placed on the form, a custom object added to property of the form and its the same result.
Below is an example of what i'm talking about, the OlePublic class and the code placed in a button on a basic form with only the OnComplete and OnError methods and having the DataSession=2 property.

Notice that the variable used as a proxy is a local variable, meaning that at the end of the method it should release itself, but if i click on the button with that code, then when i close the form it's datasession is still active (doesn't destroys as it should).

The COM class i instantiate with CreateThreadObject() function is the following:

Define Class SiteUserManager As Session OlePublic
DataSession = 2 && you should always run each object in their own datasession
CallInfo = .Null. && "magic" property

oSiteSql = .Null.
lRelease = .F.
Enddefine && i've commented all the methods trying to find the bug, this is all that's left of it

On a basic form, setup with DataSession=2 (private data session) i've placed a command button that has the following code in it's Click event:

Local loTh
*loTh = CreateThreadObject('ThWorks.SiteUserManager',thisform,.T.)
loTh = CreateThreadObject('ThWorks.SiteUserManager',thisform,.F.)
Wait Window loth

The thing is, that in the same dll i have the class you've given me, with the timer in thread ( and when i use that i have no problems, when the form goes, it's datasession goes too.


btw, do i need some special initialization for the vfp2c32.fll in order to use CreateThreadObject() ?! and what does 'threadsafe' icon means in the chm file ?! :)

Aug 11, 2011 at 12:58 PM
Edited Aug 11, 2011 at 6:20 PM


this was a bug indeed.

I had to use tricky code to get a COM object reference (interface pointer) from the passed in Foxpro callback object.

Should work fine now in the new version of VFP2C32 I've just uploaded.

"do i need some special initialization for the vfp2c32.fll in order to use CreateThreadObject() ?!"


"what does 'threadsafe' icon means in the chm file ?! :)"

All functions with the green threadsafe icon are also accessible in the threadsafe version (vfp2c32t.fll) of the library.

You have to use this version inside multithreaded Visual FoxPro COM servers - the normal vfp2c32.fll is only safe to use from a Visual FoxPro executable.

The new version also contains the changes to the help system of VFP2C32 you've proposed in the comments section.


Aug 11, 2011 at 9:57 PM

I'm more than pleasantly surprised.

Thank you Christian :)