>Ed,
>
>>>Since the problem appears to be with the integer and not the string fields being passed, I think it's a different problem.
>
>The second parameter of the call is supposed to be a 2-byte int according to the docs. I can't find a 2-byte data type in VFP, so I am passing that parameter as a constant at this point. Could the problem be here?
>

That's a VFP datatype of SHORT; alternatively, use an INTEGER - INTEGER is represented small-Endian, so that the first two bytes of a 4 byte integer are the low-order representation.

>
>>You can always pass the address of a buffer in place of a string (use INTEGER rather than STRING @; use CLSHEAP to allocate a buffer of large size and pass the buffer to the DLL call by ref, receiving back the result, and then use the GetMem or GetMemString UDFs from CLSHEAP to copy out the contents of the buffer to a standard string.) Make sure to allocate a buffer of adequate size to hold the result. I use CLSHEAP buffers to copy BSTR data all the time, and in the vast majority of cases, a large string variable inited and passed by ref (prefix with @ in the call) and declared as STRING @ in the DECLARE...DLL would work just fine.
>>
>
>I tried this (I'll find CLSHEAP useful, I'm sure...thanks)
>
>

declare long bConnect in dClient integer ptrHostID, short portNum, ;
>							integer tcpHandle, integer maxTime
>oHeap = createobject('heap')
>ptrIpaddress = oHeap.alloc(256)
>tcpHandle = 0
>? oHeap.copyTo(ptrIpaddress,'127.0.0.1')
>? bConnect(ptrIpaddress, 8227, @tcpHandle, 0)

>And I get the same exception. Would writing a wrapper DLL in VB (somehow converting the data types in VB) be a possible solution? Or is that a bad workaround?
>
You might try adding the terminating null (CHR(0) to the IP Address - eg '127.0.0.1'+CHR(0)

If you do a wrapper, simply create an in-process server in VB, and use COM rather than DLL calls to let VFP access the wrapper; it cleans up data conversion issues nicely.