>First off, if VFP differentiates between an INTEGER and a LONG (presumably 2 and 4 bytes, respectively?), the hInternet parameter should be a LONG. Under 9x, this change may have no practical result, but in NT failing to use the full 32bits of a handle will nearly always cause problems.

VFP does differentiate. And I was having problems with this. The error being returned was "The handle passed is the wrong type", or something to that effect. So I ws confident that changing the declaration to use a LONG instead of an integer would change things, and it didn't. I have a bunch of other WinInet wrappers written, and I went back and doublecheked them, and they too are using INTEGER for hInternet, with no problems.

I'm not sure what happened, but it works now. I crashed VFP a couple of times, and the last time when I reentered and ran the code, it worked. Beats me.


>DECLARE INTEGER InternetOpen IN WININET.DLL ;
>STRING, ;
>INTEGER, ;
>STRING, ;
>STRING, ;
>INTEGER
><<<
>
>Ditto here.
>

And ditto. This function is exactly as I have always used it with success.

>>>>
>hInternet = InternetOpen("EKraft Web Application", 0, NULL,NULL,0)
><<<
>
>What's this call returning?

A big number that appears to be a valid handle.


>>>>
>lpdwBufferLength = 0
>lpBuffer = SPACE(0)
>dwOption = NumToDWord(41)
>?InternetQueryOption(hInternet, dwOption, @lpBuffer, @lpdwBufferLength)
>
>41 is the value for a valid option as defined Wininet.h, and NumToDWord is a VFP function that does what its name implies. The call returns 0 (failed), and GetLastError returns the code for "Parameter is Incorrect"
><<<
>
>(41 equates to INTERNET_OPTION_USER_AGENT, right?)

You got it. I was just using that to get the prototype working. I am actually working on a function that can set the proxy username and password for proxy servers that require a login with each connection.

>I immediately felt the zero-length buffer would be a problem, but in this case that should be okay, with the last parameter returning the correct length and a lasterror of "insufficient buffer."

Yeah, I ran it first with a zero length buffer, and it returned that the buffer was too small. I read the value in lpdwBufferLength and changed the initial buffer size to that value (23), and it worked like a charm. Have any idea if I can count on that buffer size, or should my code always involve 2 steps?