>Your last paragraph confuses me:
>>The question is whether or not VFP is actually handling the references call properly in this case. In the past, anything other than one of the basic "primitives" had to be passed as a string when calling by reference (and the result parsed out).
>
>Certainly, this has not been the case since VB5 -- maybe "in the past" refers to VB3?

I was referring to VFP6 ... and "DLLs". Maybe one can get better mileage with VB Automation Servers.

In any event, when one makes calls to DLLs from VFP, one has to "DECLARE" them ... including the "types" of the parameters and return values.

There simply is no "variant" type in the syntax when DECLAREing DLLs (and "DLLs" was what the post was refering to).

Maybe it works (for automation servers) if you guess correctly at what type the variant is going to be, but fails if you guess wrong; eg. initializing the VFP variable to "numeric" when the VB variant is actually a "string" (in this case).

In any event, there is a certain amount of translation that VFP has to do in these calls; there is no actual "call by reference" when dealing with calls to a non-VFP DLL ... an intermediate process is required to perform the correct mapping between the "VFP memory pool" and that of the "target". If VFP doesn't understant the rules, the call won't work.