>This cannot work. VFP will pass a pointer for each string, the pointer will be interpreted as an integer and its first byte will be taken as BYTE (so, an 8-bit integer), etc. If the byte is by ref, the function might try to modify its value... and this will blow everything in VFP.
>
Hi Vlad,

Why? You're simply passing a pointer to allocated memory. If you've allocated sufficient space, there shouldn't be a problem. A BYTE is 8 bits. So is a one character string. I don't see why that would blow up VFP. Consider the following

I don't know how much difference the actual declaration makes when working with values which are passed by reference. Two things always concernn me when working with the API and passing things by reference. First, allocating the proper amount VFP memory to receive the value being returned. Second, how VFP interprets the value coming back. To illustrate, consider the declaration of GetDiskFreeSpaceEx() (that I use in my workaround FAQ for SYS(2020) and DISKSPACE()). Here's the declaration as shown in the SDK and followed by my translation in VFP

// C declaration
BOOL GetDiskFreeSpaceEx(
  LPCTSTR lpDirectoryName, // pointer to the directory name
  PULARGE_INTEGER lpFreeBytesAvailableToCaller, // receives the number of bytes on
                                               // disk available to the caller
  PULARGE_INTEGER lpTotalNumberOfBytes, // receives the number of bytes on disk
  PULARGE_INTEGER lpTotalNumberOfFreeBytes // receives the free bytes on disk
* VFP Declaration
DECLARE INTEGER GetDiskFreeSpaceEx IN Win32API;
  STRING @lpDirectoryName,;
  STRING @lpFreeBytesAvailableToCaller,;
  STRING @lpTotalNumberOfBytes,;
  STRING @lpTotalNumberOfFreeBytes

As you know, PULARGE_INTEGER is a pointer to a large (64 bit) integer (which in reality is a structure made up of two DWORDS). Since VFP is so loosely typed, one might assume that simply declaring some numeric values would result in VFP allocating 8 bytes (assuming double precision floating points) as a minimum for each variable. However, declaring the function with INTEGER instead of STRING, and passing numeric values results in the wrong values being received by VFP. Using the declaraion above and passing strings initialized to REPLICATE(CHR(0), 8), then converting the return values is the only way to retrieve the correct values.

AFAIK, DLLs don't care about the type of the information coming in. To the best of my knowledge, when things are passed by reference, only a pointer to the memory to be filled is passed, with no descriptor (as VFP passes to its functions). Therefore, one consideration that has to be made is that you must allocate enough VFP memory to properly hold the values being returned. Given this consideration, I would assume that as long as the VFP memory is properly allocated it shouldn't matter if you declare a BYTE data type as a STRING, SHORT or even INTEGER in VFP unless it's in a structure.