Hey Gerry. Okay, I understand now -- I think we were talking past each other, because my reading of his original post was that this was a VB OLE DLL, and not a API-Style DLL requiring a Declare. Take a look again at his original point.

I agree with everything you have said when dealing with these style API calls. I was talking about VFP calls to a VB OLE component.

>>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.