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 computer.

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.