>>>>Hi,
>>>>
>>>>I've been using an FTP Client written in VFP that I probably got from here or the UT, but I can't remember from where or who wrote it. See the attached image.
>>>>
>>>>Recently a client started to complain that the progress bar does not close and the download sticks at 100% but the number of bytes downloaded does not match the actual file size.
>>>>
>>>>I've verified that the file has successfully downloaded and they can click on the cancel button and the progress bar closes, but it does confuse the user. I've had a quick look at the code and didn't see where the bug is at first glance. Because of my limited time I was hoping someone knows where this class came from so I can find out if there is a newer version which may fix this bug. Failing that I guess I've got to dig into the code.
>>>
>>>I have a couple of FTP places where the site's timeout is shorter than the time it takes to upload the file. Sometimes it happens that the server keeps the connection open until the file is uploaded, but then disconnects before it sends confirmation that the file is sent OK, so the client stays more or less stuck - clicking cancel, reconnecting, then checking the file size takes some time, because there's some miscommunication between the client and the server, and I have to wait for the client's own grace period to pass. Generally, after the client has been seemingly stuck at 100%, the file was actually uploaded fine, it's just that the confirmation never arrived, because the "show me the directory again" command was sent when the server already disconnected. This is all based only on observation, didn't try to debug the issue.
>>>
>>>But that's manual operation. When I upload stuff programmatically, it's only to my website, and those files are short, so this didn't happen (using old Chilkat's freebie ActiveX).
>>
>>Hi Dragan,
>>
>>in this case it is downloading files that's the problem and it seems that the file size it is getting is bigger than the file size on the server! This seems to be why the process is not terminating. Looks like I need to spend the time debugging this.
>>
>>< later > It turns out this is a class developed by Sam Thornton based on someone else's work. He seems to have disappeared. He referred to two web sites in his code:
>>
>>http://www.visualfoxpro-developers.com
>>http://www.sigma-software.com
>>
>>Neither of which is active anymore.
>>
>>Anybody know how to contact him? Or anyone know how this class works and able to help me debug it?
>
>Frank,
>
>Like told you in my previous message, I am convinced Sam has a big health problem.
>I will have a look to see how his code can be modified, but dont expect that before Sunday next. Meanwhile there is a close button on the progress bar, so if users feel uneasy, just let them close the bar, closing the thermometer will not close down the up- or download process.
>
>
>Regards,
>
>Koen


Hi Koen,

sorry, I did not understand that that was what you meant by there being a problem contacting Sam. I hope he gets better.

Using the Cancel button on the progress bar is a bit counter intuitive for the users so I really need to find out what the real problem is. It appears to me that the code logic is something like this:

Get the total file size to download
Loop until sum of downloaded parts equals total file size
Stop and report success

However, the sum of the downloaded parts is exceeding the total file size. I don't understand how this could be possible. I also don't quite understand how the API calls seem to automatically loop.

I look forward to your feedback on this when you get the chance.

Thanks