Board index » cppbuilder » Problem with TIdFTP

Problem with TIdFTP


2005-06-21 03:18:46 AM
cppbuilder87
Hi, I'm using TIdFtp version 6.0, the version that came with BCB6. The
problem I'm having is only occurring with on person, out of 10 testers so
far. Basically it's almost like the Get function is locking up at the end of
the file transfer. The OnWorkEnd event handler is called but after that
nothing else happens. He is able to download 10 files prior to the file it
locks up on, which is 62MB in size and the other files are all much smaller.
It locks up at the exact same point every time.
The only major difference I've been able to determine so far is that he is
using Windows 2000 and everyone else is using XP, except for one which is
using Windows ME.
Reviewing the server logs show that the file transfer is actually complete,
then an abnormal termination occurs (which I'm assuming is the lockup).
I should also mention that the entire download function is contained within
a subthread, so I'd imagine my code needs work to be 100% threadsafe. The
thread never terminates because the caption of the Cancel Button should
change from 'Cancel' to 'Close' in the ThreadDone function.
Another question on the side is if I need to use Synchronize in the OnWork
event for updating the progressbar?
Here is the download function itself:
I used Remy's code for the Exception handling, but had to change
CheckForDisconnect(false, false)
to Disconnect() because the CheckForDisconnect function was not
disconnecting the client when it was needed.
It would loop the 10 times and abort the download rather than restarting the
download like it should. Had the same results with Quit().
bool Download(AnsiString const FileName, AnsiString const FullPath,
AnsiString const RemoteDir, TIdFTP *Ftp)
{
bool Result = false;
int Retry = 10;
do
{
try
{
if(!Ftp->Connected())
{
Ftp->Connect();
Ftp->ChangeDir(RemoteDir);
}
Ftp->Get(FileName, FullPath, true);
Result = true;
}
catch(EIdProtocolReplyError&)
{
Retry = 0;
Ftp->Disconnect();
}
catch(EIdSocketError&)
{
Ftp->Disconnect();
}
catch(Exception&)
{
// Since this is the catch all, I'd rather just start the connection
all over in case the socket is messed up
Ftp->Disconnect();
}
}while( (!Result) && (--Retry>0) );
return Result
}
Here is how I call the download function each time.
<snip from TInstallThread::Install()>
if(!Download("Ab1.cmp", FullPath, RemoteDir, Form8->Ftp1))
{
Msg = "Unable to download AM.nfo";
Synchronize(UpdateStatus);
return;
}
Msg = "Decompressing Directory Database.";
Synchronize(UpdateStatus);
The Msg 'Decompressing Directory Database never shows up.
Here is the UpdateStatus Function
void __fastcall TInstallThread::UpdateStatus(void)
{
Form8->fldInstall->Lines->Add(Msg);
}
And finally here is the InstallThread class itself:
class TInstallThread : public TThread
{
private:
// Updates status box (TRichEdit)
void __fastcall UpdateStatus(void);
// Updates a couple of labels regarding File Name, File Size, and sets
the Progressbar max to FileSize
void __fastcall UpdateFileInfo(void);
AnsiString Msg; // used to keep track of the text to add to the
TRichEdit
AnsiString FName; // File Name to set the TLabel to
AnsiString FSize; // File Size to set the TLabel to
protected:
void __fastcall Execute();
void __fastcall Install(void);
public:
__fastcall TInstallThread(bool CreateSuspended);
AnsiString InstallDirectory; // Stores the text from TEdit field
upon thread creation.
};
Thanks in advance for any help,
Thomas
 
 

Re:Problem with TIdFTP

"Tom" < XXXX@XXXXX.COM >wrote in message
Quote
Hi, I'm using TIdFtp version 6.0, the version that came with BCB6.
BCB6 ships with Indy 8.0, which is a very old version that is no longer
supported. Indy 9 has many features and bug fixes over Indy 8, and Indy 10
is the current version being actively developed now.
Quote
Another question on the side is if I need to use Synchronize in the
OnWork event for updating the progressbar?
Yes.
Quote
I used Remy's code for the Exception handling, but had to change
CheckForDisconnect(false, false) to Disconnect() because the
CheckForDisconnect function was not disconnecting the client
when it was needed.
It wasn't supposed to be. CheckForDisconnect() doesn't actually disconnect
the client. It only checks if the socket has been disconnected by the other
party and throws an exception if so. You still need to call Disconnect() to
release the socket resources.
Gambit