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
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.