I've got a timer in a very small "listener" app that checks a web service and changes data in the local database based on WS returned records. I vaguely recall somebody saying timers in VFP were bad (at some point). Was it a memory leak or something? Tapping into this list's vast years of experience with this question. So far, my app works flawlessly, pretty much on timer cue, and doesn't appear to have any memory issues.
Was just curious about this vague recollection. Thanks.
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
mbsoftwaresolutions@mbsoftwaresolutions.com wrote on 2018-01-24:
I've got a timer in a very small "listener" app that checks a web service and changes data in the local database based on WS returned records. I vaguely recall somebody saying timers in VFP were bad (at some point). Was it a memory leak or something? Tapping into this list's vast years of experience with this question. So far, my app works flawlessly, pretty much on timer cue, and doesn't appear to have any memory issues.
Was just curious about this vague recollection. Thanks.
Mike,
I don't remember it being a memory leak. I know, in most cases, it will stop other running code to run. If your executable is only there to run your timer, and the one process, it will probably be fine.
Tracy Pearson PowerChurch Software
I thought it was a CPU hog. Making the call to the system for the time 100,000 time in a single min.
On Wed, Jan 24, 2018 at 2:35 PM, Tracy Pearson tracy@powerchurch.com wrote:
mbsoftwaresolutions@mbsoftwaresolutions.com wrote on 2018-01-24:
I've got a timer in a very small "listener" app that checks a web service and changes data in the local database based on WS returned records. I vaguely recall somebody saying timers in VFP were bad (at some point). Was it a memory leak or something? Tapping into this list's vast years of experience with this question. So far, my app works flawlessly, pretty much on timer cue, and doesn't appear to have any memory issues.
Was just curious about this vague recollection. Thanks.
Mike,
I don't remember it being a memory leak. I know, in most cases, it will stop other running code to run. If your executable is only there to run your timer, and the one process, it will probably be fine.
Tracy Pearson PowerChurch Software
[excessive quoting removed by server]
On 2018-01-24 15:37, Stephen Russell wrote:
I thought it was a CPU hog. Making the call to the system for the time 100,000 time in a single min.
Well that's why you have to be smart about it, Stephen, and only call it every X minutes. In my case, anywhere between 5-15 minutes. Resources have shown it to be not even noticeable, at least in terms of memory.
Point in question is knowing what time it is now. When you start the timer it just keeps running till you turn it off. If you want to know if 10 min has transpired then it is still running for that 10 min.
On Wed, Jan 24, 2018 at 4:52 PM, < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 2018-01-24 15:37, Stephen Russell wrote:
I thought it was a CPU hog. Making the call to the system for the time 100,000 time in a single min.
Well that's why you have to be smart about it, Stephen, and only call it every X minutes. In my case, anywhere between 5-15 minutes. Resources have shown it to be not even noticeable, at least in terms of memory.
[excessive quoting removed by server]
[image: MailTag] I have a DLL that handles major timer issues (can't remember where I originally acquired it) that are not form constrained. Shut down tasks being chief among those. I've used timers on forms with no real issues that I've noticed. I do have a check that makes sure that I'm not running in debug mode tho.
----------------------------- Michael Oke, II okeind@gmail.com 661-349-6221 -----------------------------
On Wed, Jan 24, 2018 at 3:01 PM, Stephen Russell srussell705@gmail.com wrote:
Point in question is knowing what time it is now. When you start the timer it just keeps running till you turn it off. If you want to know if 10 min has transpired then it is still running for that 10 min.
On Wed, Jan 24, 2018 at 4:52 PM, < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 2018-01-24 15:37, Stephen Russell wrote:
I thought it was a CPU hog. Making the call to the system for the time 100,000 time in a single min.
Well that's why you have to be smart about it, Stephen, and only call it every X minutes. In my case, anywhere between 5-15 minutes. Resources have shown it to be not even noticeable, at least in terms of memory.
[excessive quoting removed by server]
On Wed, Jan 24, 2018 at 12:11 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
I vaguely recall somebody saying timers in VFP were bad (at some point). Was
Timers are like chainsaws. Not too bad, as long as you know which end to hold onto.
Is your plan to run the app in perpetuity, syncing data, or does this just run occasionally? A regular VFP app has the tendency to accumulate cruft over time, and VFP (and Windows) are best restarted daily.
I've seen problems with Timers (and even apps launched from the Windows Scheduler) where something keeps the app from completing, say a slow network connection or errant modal dialog, and the applications will stack up. If a resource is locked exclusively, later launches of the app get stuck. If the slowdown is suddenly released, you can have the unintended effect of multiple invocations trying to complete at the same time, leading to duplication, stack faults or crashes.
Windows Scheduler has facilities built in to terminate an application if it doesn't complete in a specified time range. With VFP, that might be tricky to duplicate: turn off the timer to avoid duplicates, and set a watchdog timer to CLEAR ALL, CLOSE ALL, RELEASE ALL, QUIT might do it. But then the timer is off: you'd likely want to signal that with a lock on a DBF, as the lock would clear when the app was closed.
See? Multithreaded asynchronous coding is simple!
I always used to find when developing comms software where VFP timers are used to poll the input ports that the best thing to do in the Timer Event is to immediately disable the timer.
Despite the logic and documentation that says that a timer event cannot fire until the current timed event has completed (single threading), on many occasions VFP would decide for no reason to stack up timer events when the system was not ready to process them - usually when the system was under load.
The obvious way to deal with this is to change from a "Polled event" to an "interrupt driven" model but the IEEE interface I was using at the time wasn't intelligent enough to generate interrupts - hence the need to poll the input port on a frequent basis.
Dave
--------------------------------------------------------------- This communication and the information it contains is intended for the person or organisation to whom it is addressed. Its contents are confidential and may be protected in law. If you have received this e-mail in error you must not copy, distribute or take any action in reliance on it. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email.
Flexipol Packaging Ltd. has taken every reasonable precaution to minimise the risk of virus transmission through email and therefore any files sent via e-mail will have been checked for known viruses. However, you are advised to run your own virus check before opening any attachments received as Flexipol Packaging Ltd will not in any event accept any liability whatsoever once an e-mail and/or any attachment is received.
It is the responsibility of the recipient to ensure that they have adequate virus protection.
Flexipol Packaging Ltd. Unit 14 Bentwood Road Carrs Industrial Estate Haslingden Rossendale Lancashire BB4 5HH
Tel:01706-222792 Fax: 01706-224683 www.Flexipol.co.uk ---------------------------------------------------------------
Terms & Conditions:
Notwithstanding delivery and the passing of risk in the goods, the property in the goods shall not pass to the buyer until the seller Flexipol Packaging Ltd. ("The Company") has received in cash or cleared funds payment in full of the price of the goods and all other goods agreed to be sold by the seller to the buyer for which payment is then due. Until such time as the property in the goods passes to the buyer, the buyer shall hold the goods as the seller's fiduciary agent and bailee and keep the goods separate from those of the buyer and third parties and properly stored protected and insured and identified as the seller's property but shall be entitled to resell or use the goods in the ordinary course of its business. Until such time as the property in the goods passes to the buyer the seller shall be entitled at any time
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Ted Roche Sent: 25 January 2018 15:26 To: profox@leafe.com Subject: Re: Timers in VFP
On Wed, Jan 24, 2018 at 12:11 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
I vaguely recall somebody saying timers in VFP were bad (at some point). Was
Timers are like chainsaws. Not too bad, as long as you know which end to hold onto.
Is your plan to run the app in perpetuity, syncing data, or does this just run occasionally? A regular VFP app has the tendency to accumulate cruft over time, and VFP (and Windows) are best restarted daily.
I've seen problems with Timers (and even apps launched from the Windows Scheduler) where something keeps the app from completing, say a slow network connection or errant modal dialog, and the applications will stack up. If a resource is locked exclusively, later launches of the app get stuck. If the slowdown is suddenly released, you can have the unintended effect of multiple invocations trying to complete at the same time, leading to duplication, stack faults or crashes.
Windows Scheduler has facilities built in to terminate an application if it doesn't complete in a specified time range. With VFP, that might be tricky to duplicate: turn off the timer to avoid duplicates, and set a watchdog timer to CLEAR ALL, CLOSE ALL, RELEASE ALL, QUIT might do it. But then the timer is off: you'd likely want to signal that with a lock on a DBF, as the lock would clear when the app was closed.
See? Multithreaded asynchronous coding is simple!
-- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com
_______________________________________________ Post Messages to: ProFox@leafe.com 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/CACW6n4tJ_NqnEsSBBOTAAVQ3nvw81kuvBNzt... ** 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.
On 2018-01-25 10:56, Dave Crozier wrote:
I always used to find when developing comms software where VFP timers are used to poll the input ports that the best thing to do in the Timer Event is to immediately disable the timer.
Yep...that's what I do too. First line in timer event turns it off, then re-enables when done.
-
Dave Crozier -
Ken Dibble -
mbsoftwaresolutions＠mbsoftwaresolutions.com -
Michael Oke, II -
Stephen Russell -
Ted Roche -
Tracy Pearson