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:[email protected]] On Behalf Of Ted Roche
Sent: 25 January 2018 15:26
To: [email protected]
Subject: Re: Timers in VFP
On Wed, Jan 24, 2018 at 12:11 PM,
<[email protected]> 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: [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/cacw6n4tj_nqnessbbotaavq3nvw81kuvbnzt9pumol0ifjg...@mail.gmail.com
** 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.
_______________________________________________
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/[email protected]
** 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.
