Something make me click on your website link, Ken, and I was surprised to see you work in the Binghamton, NY area. My wife is the from Elmira/Corning and I've been through your pretty town many times.
Paul
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ken Dibble Sent: Wednesday, January 24, 2018 11:32 AM To: profoxtech@leafe.com Subject: Re: Timers in VFP
I vaguely recall somebody saying timers in VFP were bad (at some point).
I have a timer that tracks user activity and shuts down my application if there has been no activity for a period of time. It generally works well, but I've had a few issues with it:
1. Time is *very* approximate. If I configure it to shut down after 15 minutes without activity, I can expect it to go at least 15 minutes, but as long as 20 to 25 minutes. This seems to be affected by whatever else is happening on the machine.
2. Timers complicate debugging. I think they contribute to the fact that the debugger doesn't always land on the actual line of code where an error occurred. And if the timer is going to force a jump to some other place, or shut down the application, you need to have a routine to turn it off for your "debug mode", or you won't be able to spend much time analyzing things in the debugger.
3. I have speculated--with no proof--that timers contribute to incidents where VFP doesn't necessarily execute code in the order in which it is encountered. For example, various screen painting/updating issues. Sometimes you can call .Refresh() or .Paint() until you're blue in the face and it just doesn't happen until VFP gets done doing whatever it thinks is more important.
I, too, recall this issue being discussed and I think some people had some even more esoteric points.
Ken Dibble www.stic-cil.org
[excessive quoting removed by server]