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?


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

This DLL is very critical to what I need to do here, thank you for your help.