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.

>Chilkat FTP satisfies all my needs for FTP... but now a now need arises.
>
>Some users complain that the machine freezes on a FTP download. Since the users of this app are generally less computer literate than the average, I presume they don't know the difference between "machine freezes" and "app freezes", though either is possible.
>
>Now the least I can try to do is to have some progress indicator. However, once I issue a This.oftp.Getfile(lcFromFile, lcToFile), it's all beyond my control - the ActiveX takes over and anything I do will just have to wait until the download finishes or times out.
>
>If anyone knows how to at least download a file in chunks, or maybe if a timer would still work, or... should I just play an animated gif, or what? Does anyone have any experience with this?