I don't like to open up a can of worms, but I'll do. With a benefit of enabling to know a lot more than just the Internet connection state and with an outlook to be able to enhance VFPs CreateObject capabilities.
First of all, why? I faintly remembered InternetGetConnectedState had to do with the dial-up sate of a computer, and since we're away from that and in the era of mostly permanent DSL Modem or other internet connections, I thought I look up if there's a catch to using InternetGetConnectedState.
InternetGetConnectedState documentation says: Note Using this API is not recommended, use the INetworkListManager::GetConnectivity method instead.
So I began digging. To cut to the chase, here's how you can follow that recommendation and make use of the NetworkListManager in VFP:
Code:
Clear
? ComputerIsConnectedToInternet()
Function ComputerIsConnectedToInternet()
#Define CLSID_NetworkListManager "{DCB00C01-570F-4A9B-8D69-199FDBA5723B}"
#Define IID_INetworkListManager "{DCB00000-570F-4A9B-8D69-199FDBA5723B}"
Local lcIsConnectedToInternet, loNetworkListManager
Try
loNetworkListManager = CreateObjectEx(CLSID_NetworkListManager,'',IID_INetworkListManager)
lcIsConnectedToInternet = Iif(loNetworkListManager.IsConnectedToInternet,"Yes","No")
Catch
lcIsConnectedToInternet = "Unknown"
EndTry
Return lcIsConnectedToInternet
EndFunc
I put the CreateObjectEx in a Try..Catch block, as it's an interface needing Vista or later Windows, so when it doesn't work the status is unknown. You could change it to using the logical values .T., .F. and .NULL. instead. And, of course, the catch block could revert back to using InternetGetConnectedState, it should only be necessary on XP and that's a dying species. I know POS systems still make use of it.
You can get more info. Just a short outlook, what else the NetworkListManager can show you:
Code:
=ListNetworks()
Procedure ListNetworks()
#Define CLSID_NetworkListManager "{DCB00C01-570F-4A9B-8D69-199FDBA5723B}"
#Define IID_INetworkListManager "{DCB00000-570F-4A9B-8D69-199FDBA5723B}"
Local lcIsConnectedToInternet, loNetworkListManager
loNetworkListManager = CreateObjectEx(CLSID_NetworkListManager,'',IID_INetworkListManager)
For Each loNetwork in loNetworkListManager.GetNetworks(3)
? "Network:", loNetWork.GetName(), Iif(loNetWork.IsConnected,"Connected","Not Connected"), Iif(loNetWork.IsConnectedToInternet,"(Internet)","")
EndFor
EndProc
There's more to it, not only regarding NetworkListManager. Before using CreateObjectEx with the CLSID and IIDs I came across a lot of things I'll just list here:
Creating the NetworkListManager in In C++:
Creating the NetworkListManager in Alaska xbase++:
[URL unfurl="true"]http://news.alaska-software.com/readmessage?id=%3C14696f1f$2f06d883$e308a@news.alaska-software.com%3E&group=public.xbase%2B%2B.activex[/url]
Using CoCreateInstance in VFP:
And then I remembered CreateObjectEx also has the CLSID (Class ID) and IID (Interface ID) parameters you need to get at such classes. But Calvin Hsia's article is useful nevertheless, it teaches a bit about COM usage better than VFPs simpler CreateObject() can do. At the time he wrote that VFP7 was extended in DECLARE providing a type "OBJECT", that enables getting an object from such a DECLARE DLL parameter being an address of an object. And VFP7 also didn't have CreateObjectEx(). Nevertheless, CoCreateInstance has some more parameters CreateObjectEx() lacks and so in other cases, you might gain something from that.
Bye, Olaf.
Olaf Doschke Software Engineering
