Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Test for internet connection... 2
- Thread starter Mandy_crw
- Start date
Mike Lewis
Programmer
Hi Mandy,
Have a look at faq184-4969 (by Mike Gagnon). Most of it is concerned with sending emails, which you can ignore. But there is also some code for a procedure named DisplayState, which will tell you if there is a connection.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Have a look at faq184-4969 (by Mike Gagnon). Most of it is concerned with sending emails, which you can ignore. But there is also some code for a procedure named DisplayState, which will tell you if there is a connection.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
-
1
- #3
Mike Lewis
Programmer
I've just noticed that, in addition to the code I linked to (above), you need to do a DECLARE. I think the following is all you need:
I've just tested it, and it works OK for me.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Code:
Procedure displayState
Declare SHORT InternetGetConnectedState In wininet.Dll;
INTEGER @lpdwFlags, Integer dwReserved
Local lConnected
lConnected = .F.
lpdwFlags = 0
If InternetGetConnectedState (@lpdwFlags, 0) = 1
lConnected = .T.
Endif
Return lConnected
EndprocI've just tested it, and it works OK for me.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
-
1
- #4
Chris Miller
Programmer
There is a windows API function for that:
Chriss
Code:
Declare SHORT InternetGetConnectedState In wininet.dll INTEGER @lpdwFlags, Integer dwReserved
Local lpdwFlags, llConnected
lpdwFlags = 0
Store InternetGetConnectedState(@lpdwFlags, 0)=1 To llConnected
? 'You are '+IIF(llConnected,'','not ')+'connected to the internet.'Chriss
- Thread starter
- #5
- Thread starter
- #6
Steve Meyerson
Programmer
Try this, Mandy:
where 'X\' is the path to the LAN "server"
and "filename.ext" is any file always on the server.
Steve
Code:
lConnected = FILE('X:\filename.ext')where 'X\' is the path to the LAN "server"
and "filename.ext" is any file always on the server.
Steve
Gerrit Broekhuis
Programmer
Hi Mandy and Steve,
I would add a TRY…CATCH…ENDTRY to prevent errors when the X: drive is not available.
Regards, Gerrit
I would add a TRY…CATCH…ENDTRY to prevent errors when the X: drive is not available.
Regards, Gerrit
Steve Meyerson
Programmer
Hi Gerrit,
I tried it "as-is" with a fictional path & filename. It didn't produce an error for me. However, the TRY/CATCH surely wouldn't hurt, just in case.
Steve
I tried it "as-is" with a fictional path & filename. It didn't produce an error for me. However, the TRY/CATCH surely wouldn't hurt, just in case.
Steve
Chris Miller
Programmer
It's OKAY to check LAN availability by
But please don't take "\\sharename\yourappdata\yourapp.dbc" literally, you have to adapt that to your situation.
The example is the file name of the application dbc that - no matter how many upgrades you plan in the future - will stay the same.
The only downside to that is that not finding the file because of a network outage could have long timeout, even something in the magnitude of a minute is possible. And you'd want to prevent that to happen. Therefore again actually the first step should be using some API call just like for the internet connection. Let me target that later.
Using TRY..CATCH is indeed, as you say, something that can't hurt. But I'd not leave this uncommented for putting FILE() into a TRY block. That's not helpful, because in short FILE() correctly parameterized will return .F. and not trigger an error and the CATCH block. FILE() will only trigger an error,...
1. ...if you call it with no parameter (Error 1229) or more than 2 parameters (Error 1230)
2. ...if you call it with a wrong parameter type, for example a number as filename (Error 11)
and maybe some more conditions. But in short rather a programming error, a programmer error, not an error that happens at runtime. Would VFP be strictly typed it would be errors that the compiler could already point out.
To get back to "You can always use TRY..CATCH, it causes no harm": Yes, but if you want to cover general errors you better use ON ERROR handling or in case of catching class specific errors use the Error() event of a class. TRY..CATCH isn't a bad idea in itself, though.
For making a good use of TRY...CATCH, you should try (literally put in the TRY block) something that you expect to throw an error, if it fails. That could be (to stay with my example of the DBC file):
But even that isn't really ideal, because you could also trigger an error, if the LAN connection exists, but the DBC is open exclusive by another user or other conditions that are not related to a network outage. So it would help to check what error triggered the CATCH block to run. One way to specifically only react to the case of a network outage would be using the CATCH TO Exceptionvariable FOR variant, that limits which errors to handle with the CATCH block, i.e. not the error caused by exclusive access elsewhere.
Now let me target how to use an API for that. Since Vista the core API to use would be NLM - The Network List Manager. That would also cover the internet connection detection. But unfortunately there is no easy way in for VFP, neither with a DECLARE nor CreateObject().
I also don't find any examples about usage of it. Therefore, in short, you may use the FILE() solution by Steven. Check out what happens when you remove the LAN cable or turn off WLAN about the timeout behavior of FILE(). If it answers .F. due to no LAN connection quite as fast as it answers .T. when the LAN is connected, then there is no reason to go for something more complicated. Removing the LAN cable is an easy way to force the condition that would otherwise also come up even though the cables are all connected. It's also not the ideal way to test network outage, but that topic is quite complex and mocking a condition like a network outage isn't very straight forward to cover all special cases there could be. So it also helps logging what happens, which error numbers occur etc. and then have more information when the real LAN outage case happens. Which in essence speaks for an ON ERROR handler that logs error information into an error log file, text or dbf is your choice. No idea if you already have error handling established, it's a very basic thing to have in any applcation code.
Chriss
Code:
cFile = "\\sharename\yourappdata\yourapp.dbc" && filename of a file you know must exist on a mapped network drive or file share (UNC path)
IF FILE(cFile)The example is the file name of the application dbc that - no matter how many upgrades you plan in the future - will stay the same.
The only downside to that is that not finding the file because of a network outage could have long timeout, even something in the magnitude of a minute is possible. And you'd want to prevent that to happen. Therefore again actually the first step should be using some API call just like for the internet connection. Let me target that later.
Using TRY..CATCH is indeed, as you say, something that can't hurt. But I'd not leave this uncommented for putting FILE() into a TRY block. That's not helpful, because in short FILE() correctly parameterized will return .F. and not trigger an error and the CATCH block. FILE() will only trigger an error,...
1. ...if you call it with no parameter (Error 1229) or more than 2 parameters (Error 1230)
2. ...if you call it with a wrong parameter type, for example a number as filename (Error 11)
and maybe some more conditions. But in short rather a programming error, a programmer error, not an error that happens at runtime. Would VFP be strictly typed it would be errors that the compiler could already point out.
To get back to "You can always use TRY..CATCH, it causes no harm": Yes, but if you want to cover general errors you better use ON ERROR handling or in case of catching class specific errors use the Error() event of a class. TRY..CATCH isn't a bad idea in itself, though.
For making a good use of TRY...CATCH, you should try (literally put in the TRY block) something that you expect to throw an error, if it fails. That could be (to stay with my example of the DBC file):
Code:
Local llNetworkavailable
TRY
OPEN DATABASE \\sharename\yourappdata\yourapp.dbc
CATCH
* unfortunately there's nothing to enforce the availability of the network
* so nothing more to do here
FINALLY
llNetworkavailable = DBUSED('yourapp')
ENDTRY
IF llNetworkavailable
? 'LAN is up, the database is opened'
Else
? 'The DBC couldn't be opened, maybe a network outage.'
EndifBut even that isn't really ideal, because you could also trigger an error, if the LAN connection exists, but the DBC is open exclusive by another user or other conditions that are not related to a network outage. So it would help to check what error triggered the CATCH block to run. One way to specifically only react to the case of a network outage would be using the CATCH TO Exceptionvariable FOR variant, that limits which errors to handle with the CATCH block, i.e. not the error caused by exclusive access elsewhere.
Now let me target how to use an API for that. Since Vista the core API to use would be NLM - The Network List Manager. That would also cover the internet connection detection. But unfortunately there is no easy way in for VFP, neither with a DECLARE nor CreateObject().
I also don't find any examples about usage of it. Therefore, in short, you may use the FILE() solution by Steven. Check out what happens when you remove the LAN cable or turn off WLAN about the timeout behavior of FILE(). If it answers .F. due to no LAN connection quite as fast as it answers .T. when the LAN is connected, then there is no reason to go for something more complicated. Removing the LAN cable is an easy way to force the condition that would otherwise also come up even though the cables are all connected. It's also not the ideal way to test network outage, but that topic is quite complex and mocking a condition like a network outage isn't very straight forward to cover all special cases there could be. So it also helps logging what happens, which error numbers occur etc. and then have more information when the real LAN outage case happens. Which in essence speaks for an ON ERROR handler that logs error information into an error log file, text or dbf is your choice. No idea if you already have error handling established, it's a very basic thing to have in any applcation code.
Chriss
Chris Miller
Programmer
And here's a completely different take on checking LAN connection: Don't do it at all.
In short, if your application requires LAN connection to a network share of your data for multi user support, then it's not an error to expect it as granted. Just like you don't check whether a keyboard is connected to the computer or a mouse or a display.
Usual ON ERROR logging is enough to document whenever OPEN DATABASE or USE of some DBC or DBF file in the network doesn't work. And usually there's no need to react to such errors when you look into the log for errors you might want to fix in the next version of your software. Because missing LAN is not a problem of your application, it's a problem of providing the necessary infrastructure for your software to work. And in case the software usually works and only can't function as the network has problems. The proof of that should be obvious when the network comes back again and the software works.
Let me give a simpler example: If you start up a browser and begin using it you get errors of websites or the internet not being available, you would also not blame it on Edge, IE, Chrome, Firefox, Safari, OPera or whatever Browser software to use, but take on the problem of internet connection with your internet provider, perhaps.
The reasoning to cover internet connection checks or LAN connection checks for me is mainly avoiding a long timeout before an error occurs. And then, you can get a network or internet outage in the middle of running your software, too. It always looks better if you can manage to detect the problem is outside of your software and keep it stable, not crashing due to those external problems and then even point out the problem to the user in a user friendly way and not a technical system error message.
But I didn't bother adding a LAN connection check in any software that is made for a company for internal use, at least when it's a company with their own IT department. If you do some software for a small business with no department caring for the LAN or internet, then that makes sense. IF you do it for yourself, why bother with it, you see what fails when it does. If you make these checks only at start, you can still get problems in the middle of running your application. You don't want to overcomplicate everything to make cautious checks before actually making a http request or opening a network file, just like you don't test whether a system goes into idle mode and has the display off or the lock screen or a screensaver running. You also don't check with a webcam whether there's a user in front of your software.
There is something to care about: If you have started editing data and now can't finish it fully, that surely can cause problems. Therefore dealing with database changes is done in transactions, ideally.
What's also true is, as buffers are local and not stored in the network, you usually can pick up where you were interrupted due to LAN or internet outages, once these connections come back again. But a simpler way to deal with it is exiting when the prerequisites are not met, no matter if that's at start or anywhere in between. So when you fail to store a change or open a table, the global error handling should log that as every error, and then shutdown your software, so no further harm can happen. It's a bad idea to go into some idle waiting mode, unless your software is something that acts as a service that should stay resident and continue to work even when external problems arise.
Chriss
In short, if your application requires LAN connection to a network share of your data for multi user support, then it's not an error to expect it as granted. Just like you don't check whether a keyboard is connected to the computer or a mouse or a display.
Usual ON ERROR logging is enough to document whenever OPEN DATABASE or USE of some DBC or DBF file in the network doesn't work. And usually there's no need to react to such errors when you look into the log for errors you might want to fix in the next version of your software. Because missing LAN is not a problem of your application, it's a problem of providing the necessary infrastructure for your software to work. And in case the software usually works and only can't function as the network has problems. The proof of that should be obvious when the network comes back again and the software works.
Let me give a simpler example: If you start up a browser and begin using it you get errors of websites or the internet not being available, you would also not blame it on Edge, IE, Chrome, Firefox, Safari, OPera or whatever Browser software to use, but take on the problem of internet connection with your internet provider, perhaps.
The reasoning to cover internet connection checks or LAN connection checks for me is mainly avoiding a long timeout before an error occurs. And then, you can get a network or internet outage in the middle of running your software, too. It always looks better if you can manage to detect the problem is outside of your software and keep it stable, not crashing due to those external problems and then even point out the problem to the user in a user friendly way and not a technical system error message.
But I didn't bother adding a LAN connection check in any software that is made for a company for internal use, at least when it's a company with their own IT department. If you do some software for a small business with no department caring for the LAN or internet, then that makes sense. IF you do it for yourself, why bother with it, you see what fails when it does. If you make these checks only at start, you can still get problems in the middle of running your application. You don't want to overcomplicate everything to make cautious checks before actually making a http request or opening a network file, just like you don't test whether a system goes into idle mode and has the display off or the lock screen or a screensaver running. You also don't check with a webcam whether there's a user in front of your software.
There is something to care about: If you have started editing data and now can't finish it fully, that surely can cause problems. Therefore dealing with database changes is done in transactions, ideally.
What's also true is, as buffers are local and not stored in the network, you usually can pick up where you were interrupted due to LAN or internet outages, once these connections come back again. But a simpler way to deal with it is exiting when the prerequisites are not met, no matter if that's at start or anywhere in between. So when you fail to store a change or open a table, the global error handling should log that as every error, and then shutdown your software, so no further harm can happen. It's a bad idea to go into some idle waiting mode, unless your software is something that acts as a service that should stay resident and continue to work even when external problems arise.
Chriss
Steve Meyerson
Programmer
Chris,
After reading your posts, I think I over-simplified my solution to Mandy's question.
First: "...a way to CONSTANTLY check...". Maybe a check timed every second (more or less) but might add too much overhead. Maybe there's something outside of the basic VFP functions. I don't know.
Second: I was thinking in terms of a LAN (local) or external server. But the request was for "..connection to the INTERNET.." instead. I believe FTP requires an internet connection (I'm not sure that's always true) so that could be another approach.
In either case, the solution is beyond me. Maybe we should ask for more details on Mandy's situation? [hint hint]![[dazed]](/data/assets/smilies/dazed.gif "[dazed] [dazed]")
Steve
After reading your posts, I think I over-simplified my solution to Mandy's question.
First: "...a way to CONSTANTLY check...". Maybe a check timed every second (more or less) but might add too much overhead. Maybe there's something outside of the basic VFP functions. I don't know.
Second: I was thinking in terms of a LAN (local) or external server. But the request was for "..connection to the INTERNET.." instead. I believe FTP requires an internet connection (I'm not sure that's always true) so that could be another approach.
In either case, the solution is beyond me. Maybe we should ask for more details on Mandy's situation? [hint hint]
Steve
Gerrit Broekhuis
Programmer
Hi Chris and Steve,
Personally I would not trust IF FILE() and would rather use ADIR() instead for better reliability.
Regards, Gerrit
Personally I would not trust IF FILE() and would rather use ADIR() instead for better reliability.
Regards, Gerrit
- Thread starter
- #14
Chris Miller
Programmer
Steve, no I think you forgot that the thread now has two questions, one about INTERNET and one about LAN, and your answer was to the second question.
Mandy, that's perhaps also a good case to show why it's really better to start a new thread for a new question. There's cases were it's very related, but internet and LAN are two very different things.
Chriss
Mandy, that's perhaps also a good case to show why it's really better to start a new thread for a new question. There's cases were it's very related, but internet and LAN are two very different things.
Chriss
Steve Meyerson
Programmer
You are correct. I didn't look past the first question.Chris said:
![[mad]](/data/assets/smilies/mad.gif "[mad] [mad]")
- Thread starter
- #17
- Status
Similar threads
