>Hi Ed,
>
>>All STRING declarations are ByRefs; what is passed to the API call is the same regardless of whether your DECLARE...DLL has a STRING cSomeValue or a STRING @ cSomeValue. I don't know why this occurs, and it doesn't make sense, but it does appear to be the behavior.
>
>Yes and no. As you probably know in C strings are generally passed as a pointer to the string, that's why VFP doesn't make a distiction in the call. In C terms the first is function(const char*) and the second function(char*). Both definitions produce the same code, in C it's the compiler that verifies that you don't alter the passed string.
>
>The definition doesn't really matter, but how you call the API function does matter. When you pass a string by reference, VFP passes a pointer to the actual string, when you pass it by value, it passes a pointer to a copy of the string. The following code sample illustrates this:
>

>Declare Integer GetSystemTime in Win32Api String
>lcBuffer = Space(255)
>GetSystemTime(lcBuffer)
>? ">",lcBuffer,"<"         && empty string
>GetSystemTime(@lcBuffer)
>? ">",lcBuffer,"<"         && SYSTEMTIME strucutre 

Yes, and that's as expected as well - even if you pass a non-pointer item by value as a parameter in the declaration, if you pass the actual parameter by reference, you get back the value; if you pass by value, it's unaltered. That behavior is exactly as expected.

The big difference is in the declaration, passing INTEGER dwValue passes the value itself, while INTEGER @ lpdwValue passes a pointer to the value. STRING lpstr and STRING @ lpstr pass a pointer to the string at all times; if STRING lpstr passed a pointer to the string, I'd have expected STRING @ lpstr to pass a pointer to the pointer. Since both pass the same thing, the syntax seems inconsistant.

Ed