One of the amazing things about
is that you can drop a few components on a form and within minutes have
a working program that can download or upload files to another computer.
Of course, the example programs can do this too, but it's more fun to
start from scratch and build on the program to suit your needs.
One of the components required for file transfers is TApdProtocol.
This universal component can be set to handle all of the transfer
protocols support by APRO, i.e., XModem, YModem, ZModem, and so on. Of
all those available, ZModem is by far the most used because it's more
reliable and efficient than the others. However, because of its nature,
you need to make sure of a few property settings and programming
procedures to assure smooth, reliable transfers.
ZModem presumes the sending side will get back to work even if the
carrier has been hit by a meteor or your kids (or customers) pull the
plug on their computer.
Get with the Flow
First, and foremost, be sure that Hardware Flow Control is turned on at
both ends of the connection. This includes not only at the port, via the
HWOptions property of the TApdComport, but the modem as well. Check your
owner's manual for more information.
If necessary, be sure to send a string to the modem via the Comport
component that turns on Hardware Flow Control. The preferred type of
control is RTS/CTS so try that first. Turning on HW flow control allows
the protocol to stop data transfers when necessary so that data is not
lost or buffers are filled to overflowing. The nature of the ZModem
protocol makes this more likely without flow control implemented.
In Case of Blackout
ZModem is a persistent critter. The receiving side will keep on
receiving even if the sending side has been hit by a meteor. ZModem
presumes the sending side has just taken a prolonged break and will get
back to work, eventually, even if the carrier has been lost because of
that meteor or your kids (or customer) pulling the plug on the modem or
For this reason, you should set the TApdProtocol's AbortNoCarrier
property to True. Should the carrier be lost, for whatever reason,
ZModem will give up and move on, generating an OnProtocolFinish event
with an error code other than 0. If you don't set this property and have
an automated, unattended program that attempts to receive files from
many client machines, there will be a lot of computers trying to get
through that can't. Good thing they are patient souls and not people.
Remove Your Triggers
If you have user-defined data triggers in place, remove them before you
start the transfer otherwise you could be in for trouble.
Say, for example, that you have a data trigger on the words "process
completed" and that trigger causes the application to hang-up the phone
and wait for the next incoming call. Now, you start downloading a text
file on some subject and the following sentence is transmitted: "You
should never try to do this until the process completed." The dispatcher
"sees" the magic words and fires your OnDataTrigger event handler.
Unfortunately, the file transfer was only 50% complete.
What you should do is have a method that removes the triggers before
you start the transfer and restores them, if need be, after the transfer
is completed (maybe called in the OnProtocolFinish event). In the case
above, the server machine might do something with the information in the
file and, if all is well, send "process completed" to the client so that
the two hang up. If something was wrong with the transfer or the data,
the server might send "Try again" and the client would resend the file.
As long as you're aware of some of the pitfalls and certain
considerations, the APRO components can make serial communications
programming much easier by taking care of the low level operations while
you take care of providing the features that you or your customers want.