>>THe declaration is unaffected by the need to capture a changed value - you use @ in the function call to allow any change to propagate back; declaring it in the DECLARE...DLL has a definite and different effect; LONG passes a 4 byte integer, while long @ passes a pointer to what is presumed to be a 4 byte integer. See CLSHEAP to see examples of where to use each.
>
>I got the following email from support (the author of the DLL):
>
>< snip >
>I'm not too familiar with Foxpro, but I think that it's
>strings are limited to 255 bytes and that the DLL support in Foxpro is
>limited to C-style ASCII-Z strings anyway, which won't work with binary
>data. The string type supported by our DLL is the OLE BSTR type used by
>Visual Basic.
>< /snip>
>

The STRING datatype in VFP can be 16M bytes in length assuming your system has the free memory (in theory, up to 2GB); it clearly is not ASCII-Z string types, since we can pass/retrieve data in strings that contains nulls, which would be seen as terminators in ASCIIZ strings. Since the problem appears to be with the integer and not the string fields being passed, I think it's a different problem.