>>>I think the declaration should be:

>>>DECLARE INTEGER WNetAddConnection IN Win32API;
>>>  STRING @lpszRemoteName, STRING @lpszPassword, STRING @lpszLocalName

>>>with all parameters being passed by reference. So, using your example:

>>>RETURN (WNetAddConnection(@cUNCToMap, 0, @cDriveLetter) = 0)

>>>will work.
>>>
>>
>>The code I gave does work, but you may be right. VFP seems to handle the LPTSTR ref properly even with the use of STRING cVarName rather than STRING @cVarName. It's old code from one of our classlibs at work, which we've replaced with calls to WNetAddConnection3(), which requires an HWND and an LPNETRESOURCE
>>
>>The C prototype for the API call is:
>>
>>DWORD WNetAddConnection( LPTSTR lpRemoteName, // pointer to network device name
>> LPTSTR lpPassword, // pointer to password
>> LPTSTR lpLocalName // pointer to local device name);
>>
>Hi Ed,
>
>I'm sure it does work. I think it's a good idea, however, to take as many variables as possible out of the mix. BTW, I've learned the hard way that if it says "pointer" pass it by reference. I've had VFP blow up on me numerous time from different calls by failing to pass a parameter properly.

You won't get an argument from me about this. I just grabbed some code that worked from something I had here, and that didn't require wrapper DLLs or something like POINTERS.VCX to resolve API parameter values.

On the subject of pointers, I have not seen an equivalence between a pass by ref in the API call with a STRING charVar in the DECLARE and a pass by value with a STRING @charVar in the DECLARE; in fact, where buffers are being modified by the API with a STRING @charVar, I've pretty much proved out that you can pass either by value if you don't care what happens to the resulting buffer, or by ref if you want to get the result back. If what you state is true, then STRING @charVar followed by a pass by ref wouldn't work in something like WNetGetConnection(), where the UNC is passed back in the declared buffer and you need a pass by ref to catch the result. the C prototype looks like:

DWORD WNetGetConnection(  LPCTSTR lpLocalName,  // pointer to local name
  LPTSTR lpRemoteName,  // pointer to buffer for remote name
  LPDWORD lpnLength     // pointer to buffer size, in characters
);

The DECLARE that works for me looks like:

DECLARE INTEGER WNetGetConnection IN Win32API ;
 STRING   @cLocalDrive, ;
 STRING   @cRemoteUNCBuffer, ;
 INTEGER  @nSizeOfBuffer

and the API call is made from VFP with code like:

cBuffer = SPACE(511)
nBufLen = 511
nResult = WNetGetConnection(LEFT(cDriveLetterToCheck,2)+CHR(0), ;
                            @cBuffer, ;
                            @nBufLen)

What you state would make the @cBuffer reference in the call to the API a pointer to an LPTSTR rather than as an LPTSTR, and the result would be lost, as would the @nBufLen reference be a pointer to an LPDWORD.

The above code works, and is in production at literally hundreds of sites on a wide mix of networks under 95, 98 and various flavors of NT.

Any suggestions as to why things don't work as expected from the docs?