Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
WININET.DLL Function Problem
Message
General information
Forum:
Visual FoxPro
Category:
Windows API functions
Miscellaneous
Thread ID:
00142611
Message ID:
00142944
Views:
34
>I would not rely on that function! All the wrappers around the RAS API
>are very flaky and only work if Internet Explorer is set up to AutoDial.
>If you're using a dedicated connection or even have a RAS connection
>set up as a net connection InternetCheckConnection will always return
>the same value (I think it's TRUE).
>

That explains some of my results; thanks, Rick. I can understand why the API call mis-IDs the connection type if I'm providing DNS inside the Proxy Server, but I don't understand the misqueues in status with AutoDialing enabled and dialing in progress or failed due to busy signals. Any clues other than 'the API wrappers are flaky'? Do the RAS functions like RASGetConnectStatus() return the detail properly in the RASCONNSTATUS structure? If so, and the connection details, other than a live connection exists, are needed, would it be better to use RasEnumConnections() to get a handle, and then examine the RASCONNSTATUS structure from RASGetConnectStatus()?

>In other words, don't bother... The best way to check a connection is to
>create a Socket and ping a known good address on the Internet with a
>short timeout.
>
>+++ Rick ---
>
>>>>Hi All!
>>>>
>>>>I am developing an application for release in early November (so time is critical). I am attampting to use the "InternetCheckConnection" function within WININET.DLL to detect the presence of an active Internet connection. Using the code below, I can never get a positive indication, even when IE is online and connected to the specified URL.
>>>>I am working in VFP 6.0, and any help would be much appreciated, especially if there is another way to positively detect an Internet connection without recourse to WinSock (this is needed to differentiate between a modem connection and a LAN connection).
>>>>
>>>>Thanks
>>>>
>>>>Terry Bridges
>>>>
>>>>****************************************************************
>>>> PROCEDURE CHECKCON
>>>>
>>>> LOCAL lnreturn, lcURL, lnflags, lnreserved
>>>>
>>>> lnreturn = 2
>>>> lcURL = "http://www.ndss.com"
>>>> lnflags = 1
>>>> lnreserved = 0
>>>>
>>>> DECLARE Integer InternetCheckConnection in WININET as InternetCheckConnection String @, Integer,
>>>> Integer
>>>>
>>>> lnreturn = InternetCheckConnection(@lcURL,lnflags,lnreserved)
>>>>
>>>> DO CASE
>>>>
>>>> CASE lnreturn = 1
>>>>
>>>> MessageBox ('Connection was Successful')
>>>>
>>>> CASE lnreturn = 0
>>>>
>>>> MessageBox ('No Connection Detected')
>>>>
>>>> OTHERWISE
>>>>
>>>> MessageBox ('Connection Error: '+ LTRIM(STR(lnreturn)))
>>>>
>>>> ENDCASE
>>>>
>>>> RETURN lnreturn
>>>> **************************************************************
>>>
>>>If all you need to find out is if you're connected, and the status of the connection, why not just use InternetGetConnectedState():
>>>
>>>
>>>DECLARE SHORT InternetGetConnectedState IN WININET ;
>>>   INTEGER @lpdwFlags, ;
>>>   INTEGER dwReserved
>>>
>>>nConnectFlags = 0
>>>
>>>IF InternetGetConnectedState(@nConnectFlags,0) = 1
>>>   *  We have a connection;  check the type using the flag masks
>>>   *  INTERNET_CONNECTION_MODEM
>>>   *  INTERNET_CONNECTION_LAN
>>>   *  INTERNET_CONNECTION_PROXY
>>>   *  INTERNET_CONNECTION_MODEM_BUSY (I don't have the .H file on-line)
>>>ELSE
>>>   *  We aren't connected
>>>ENDIF
>>>
>>
>>My server is back on-line; the file is WININET.H, and the flag values are:
>>
>>INTERNET_CONNECTION_MODEM        1
>>INTERNET_CONNECTION_LAN          2
>>INTERNET_CONNECTION_PROXY        4
>>INTERNET_CONNECTION_MODEM_BUSY   8
>>
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform