IdFTP.Connect springt raus

[Gloegg_FHBI]

Hallo Forum,

Ich möchte in meinem Programm ein paar Dateien nebenher hochladen. Dazu habe ich einen einfachen Thread programmiert.
Leider springt er beim Aufruf von ftp.Connect; einfach aus der Methode, ohne Exception, als hätte ich exit; aufgerufen.

Hier der Quelltext des Threads:

Delphi-Quellcode:

unit uFTPThread;

interface

uses
  Classes, IdBaseComponent, IdComponent, IdTCPConnection, IdTCPClient,
  IdExplicitTLSClientServerBase, IdFTP;

type
  TFTPThread = class(TThread)
  private
    { Private-Deklarationen }
    ftp : TIdFTP;
    fIP : string;
    fPort : integer;
    fUser, fPassword : string;
    fActive : boolean;
    fTubeFile, fUserFile : string;
    procedure UpdateUsers;
    procedure UpdateTubes;
  protected
    procedure Execute; override;
  public
    property Host : string read fIP write fIP;
    property Port : integer read fPort write fPort;
    property Username : string read fUser write fUser;
    property Password : string read fPassword write fPassword;
    property Userfile : string read fUserfile write fUserfile;
    property Tubefile : string read fTubefile write fTubefile;
    property Active : boolean read fActive write fActive;
  end;

implementation

{ TMachineThread }

uses
  SysUtils, IdFTPCommon;

procedure TFTPThread.Execute;
begin
  ftp := TIdFTP.Create(nil);
  // Binary Transfer
  ftp.TransferType := ftBinary;

  if Active then
  begin
    try
      ftp.Host := fIP;
      ftp.Port := 21;
      ftp.Username := fUser;
      ftp.Password := fPassword;
      ftp.AutoLogin := true;
      ftp.Connect;
      ftp.Quote('gtwr');
      ftp.ChangeDir('Directory');

      if fUserFile <> '' then
      begin
        UpdateUsers;
      end;
      sleep(100);

      if fTubeFile <> '' then
      begin
        UpdateTubes;
      end;
      sleep(100);

      ftp.Disconnect;
    end;
  ftp.Free;
end;

procedure TFTPThread.UpdateTubes;
begin
  fTaskname := 'Aktualisiere Schlauchdatei';
  Synchronize(setTaskname);
  ftp.Put(fTubefile,'SCHLAUCH.CSV');
end;

procedure TFTPThread.UpdateUsers;
begin
  fTaskname := 'Aktualisiere Benutzerdatei';
  Synchronize(setTaskname);
  ftp.Put(fUserfile,'USER.CSV');
end;

end.

Aufgerufen habe ich es so:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  t : TFTPThread;
begin
   t := TFTPThread.Create(true);
  t.Host := '192.169.178.20';
  t.Port := 21;
  t.Username := 'User';
  t.Password := 'password';
  t.Userfile := 'C:\temp\user.txt';
  t.Tubefile := 'C:\temp\tube.txt';
  t.Active := true;
  t.Resume;
end;

[sx2008]

Wahrscheinlich kommt es bei Connect zu einer Exception die du nicht abgefangen hast.
Exceptions innerhalb von Threads gehen sang & klanglos verloren, solange man nicht etwas dagegen tut.
Mein Tipp:
Erzeuge das TIdFTP-Objekt im Hauptthread, stelle im Hauptthread die Verbindung mit Connect her und übergebe dann das fertige Objekt deinem Thread.
Dadurch kannst du dir auch die Properties Host, Port, Username & Passwort sparen.

[himitsu]

Sang und Klanglos geht da nix unter.
Exceptions, welche in einem TThread-Ableger nicht abgefangen werden, werden gespeichert und können abgefragt werden.

PS: Wann wird eigentlich dein Thread-Objekt freigegeben?
FreeOnTerminate wird ja nicht gesetzt und selber freigeben tust du das t anscheinend auch nicht,
was demnach natürlich in einem Speicherleck enden muß.

Nja, wie dem auch sei,
* entweder du schreibst folgenden Code in eine Ereignisprozedur (mit Sender statt t) und registrierst diese bei t.OnTerminate und stellst natürlich t.FreeOnTerminate noch auf True
* oder das Selbe, nur daß DoTerminate überschrieben wird, statt OnTerminate zu nutzen
* oder du gibst irgendwo im Hauptprogramm das t frei, nachdem der Thread mit seiner Arbeit beendet hat, und führst ebenfalls vorher nachfolgenden Code aus.

Delphi-Quellcode:

if Assigned(t.FatalException) then
  ShowException(t.FatalException, nil);

// oder

if Assigned(t.FatalException) then
  ShowMessage(Exception(t.FatalException).Message);

[sx2008]

Zitat von himitsu:

Sang und Klanglos geht da nix unter.
Exceptions, welche in einem TThread-Ableger nicht abgefangen werden, werden gespeichert und können abgefragt werden.[/delphi]

Es kommt natürlich immer auch auf die Delphi-Version an.
In D5 gibt es z.B. keinen richtigen Support für Exceptions in Threads.
Man muss die Exception selbst abfangen, das Exception-Objekt in der Thread-Klasse verfügbar machen und im Hauptthread auswerten.
Wenn man nichts tut, wird die Exception weder im Programm noch im integrierten Debugger (!) angezeigt.
Sang und klanglos ist da doch eine treffende Beschreibung.

[himitsu]

Seit mindestens Delphi 7 trifft dieses ja nicht mehr zu und hier haben alle Beteiligten grade auch noch mindestens ein 2007er.

[Gloegg_FHBI]

Danke für die Antworten.
ums freigeben des Threads habe ich mich noch nicht gekümmert, das war mir erstmal egal, wichtiger war, warum das connect nicht funktioniert, bzw. in einem thread komische dinge macht.

Gestern abend hatte ich zum testen den FTP-Server meiner NAS zuhause benutzt. Heute morgen auf der Arbeit hab ich zu meinem FTP-Server von meinem Webspace gewechselt und siehe da, es funktioniert. (Ich musste nur ftp.Login; rausnehmen, da autologin per default auf true ist)
Da kam dann auch erstmal ein EIdReplyRFCError mit "You are already logged in!" aus der Delphi IDE.

Vielleicht muss ich noch Passiv/Aktiv oder eine andere verbindungseigenschaft richtig setzten, damit es dann auch zuhause im LAN klappt.

[andreasm82]

Zitat:

einfach aus der Methode, ohne Exception,

In deimem Quellcode steht ja auch gar kein Except!

Du nimmst ein try ... end; , aber verwendest kein except dabei.
try ... except ... end; würde das Problem lösen, denke ich.

Delphi-Quellcode:

  try
    // tue was
  except
    on E:Exception do
    begin
       
       showmessage(E.ClassName+':'+E.Message);

    end;
  end;

[Gloegg_FHBI]

Oh, sorry, da hatte ich den Code zum posten etwas vereinfachen wollen und das except gelöscht, aber das try drinbehalten. Im echten Programm gibt es natürlich einen except-block.
Für ein Testprogramm hatte ich dann beides rausgenommen und da hat es sich ebenso wie beschrieben verhalten.

Jedenfalls scheint es an meiner NAS zu liegen, da es mit ein paar anderen FTP-Servern ohne Probleme geklappt hat.