>Have you ever read Michelle's FTP API article in the UT magazie?
>
>Let's assume nominal proxy server and sub-mask settings at the desktops. We can also assume the network and router are reasonably sound and clean. That also means the connection is good.
>
>We can assume that the site password and user id has been logged to the FTP site successfully. And that the site is [happily] waiting for the logged in user to request a file.
>
>After the file is downloaded, we can assume the desktop assures a proper "log out"? What is a "log" jam?
>
>So what remains is the file. Is it there - or could your FTP client be waiting for it to be available - do you need an autopoll feature to requery using the FTP "DIR" command to assure the file is available before the FTP "GET" fires?
>
>When just one desktop makes the request does it work. IOW - are desktops having to wait only when more than one is requesting the file.
>
>With the MS FTP control a state change event fires when the control does some work. I trap for the state changes and send the state change message to an editbox control with a time stamp.

>do case
>case state = 0
>     StateMsg=[No Change in state]
>case state = 1
>     StateMsg=[Looking up FTP Site DNS IP address]
>case state = 2
>     StateMsg=[Successfully located DNS server]
>case state = 3
>     StateMsg=[Connecting to host computer]
>case state = 4
>     StateMsg=[Successfully connected to host computer]
>case state = 5
>     StateMsg=[Sending request to host computer]
>case state = 6
>     StateMsg=[Successfully sent request to host computer]
>case state = 7
>     StateMsg=[Receiving response from host computer]
>case state = 8
>     StateMsg=[Successfully received response from host computer]
>case state = 9
>     StateMsg=[Disconnecting from host computer]
>case state = 10
>     StateMsg=[Successfully disconnected from host computer]
>case state = 11
>     StateMsg=[Error in host communications]
>otherwise &&case state = 12
>     StateMsg=[The request is complete and all data received]
>EndCase

>It's helpful to log the state changes. The file is accumulated in a response header thingie. You could have a timer that fires every 30 senconds once the GET is executed. If the size of the response header is the same as the last time a timer event checked - your FTP client could cancel the download or message for a retry. The logged state change events might give you an indication of what was going on.
>
>Regarding chunks - my project species a chunk size of 1024 only with the "DIR" function. When the project logs in to the FTP server, the first thing it does is run an FTP "DIR". The information from that request populates a remote directory listbox on my FTP client. For the GET function, no chunk is specified.
>
>You should read Fourniers' article. You'll really like it.

This would be too much info for the intended audience of the app :). And having that info mailed back to me, that'd probably be even more than too much - they'd probably start getting all sorts of alerts, firewall acting up etc. This is a shrinkwrap thing, the FTP just needs to silently do what it needs to do and to know how it ended. Not a single excessive bit of technical info appears in front of the user's eyes - they are, ahem, very untechnical by nature.

And besides, can't switch from Chilkat to anything else at the moment, no time. Need to churn the next version ASAP. I'll read Michel's article, of course. May end up knowing more than I wanted :).