Indy 10 - Progressbar arbeitet nicht mehr mit OnWork

[hsbc]

Hallo allerseits,

ich habe mir Indy 10 installiert und einen bereits unter Indy 9 lauffähigen FTP-Server angepasst. Im Prinzip läuft wieder alles,
NUR:

die ProgressBar, welche den Datei-Upload bzw. Datei-Download anzeigen soll und mit Indy 9 hervorragend funktionierte, funktioniert nicht mehr. Ich verwende hiezu IdFTP.OnWorkBegin, IdFTP.OnWork und IDFTP.OnWorkEnd.

Hat jemand eine Idee, was unter Indy 10 hier anders abläuft, bzw. funktionieren vielleicht diese Routinen überhaupt nicht mehr?

mfg
Herbert

[hsbc]

Einen Teilerfolg kann ich bereits berichten:

Nachdem ich folgendes eingestellt habe:

Delphi-Quellcode:

IdFTP.IOHandler.SendBufferSize := 1024;
IDFTP.IOHandler.RecvBufferSize := 1024;

kann ich jetzt den Download in der ProgressBar mitverfolgen.

Warum das ganze beim Upload (noch) nicht funktioniert, ist mir immer noch ein Rätsel.

Weiss jemand, was man (vermutlich) im IOHandler setzen muss, damit auch der Fortschrittsbalken beim Upload funktioniert?


Es ist für mich ja überhaupt seltsam, dass sich jemand bemüht, derart umfangreiche Komponenten, wie die Indy zu erstellen, aber auf Umsetzungsbeispiele zur Gänze verzichtet. Die gesamten Komponenten sind dadurch FAST NULL wert. Dies sollten sich auch die Programmentwickler mal hinter die Ohren schreiben und bevor solche Komponenten zur Verfügung gestellt werden, mal umfangreiche Beispielanwendungen veröffentlichen.

mfg
Herbert

[hsbc]

Schade, dass niemand Bescheid weiss,

dann muss ich doch diesen Schritt gehen, den ich befürchtet habe:

INDY muss auf meinem Rechner sterben !


Komponenten, welche keinerlei Unterstützung bieten, haben auf meinem Rechner nichts mehr verloren...

mfg
Herbert

[Luckie]

Nun ja, wenn du vor uns auch jeglichen Code versteckst, ist es eben schwer zu helfen.

[DGL-luke]

Zitat:

Zitat von hsbc

...aber auf Umsetzungsbeispiele zur Gänze verzichtet....

Ich bin mir 100% sicher, dass es zu den Indys Demos gibt. Nein, 1000%. Es gab auf jeden Fall bei Indy9 welche, warum sollte es bei Indy 10 nicht so sein.

[Klaus01]

Vielleicht hat ja dies etwas mit Deinem Problem zu tun: http://www.indyproject.org/Sockets/B.../index.en.aspx

Grüße
Klaus

[hsbc]

Das Problem, das ich habe, ist kurz erklärt folgendes:

Ich habe ein Projekt mit Indy 9 erstellt, wo es unter anderem auch einen Fortschrittsbalken für Download und Upload gibt, welcher unter Indy 9 hervorragend funktioniert (Wird einfach im OnWork, OnWorkBegin und OnWorkEnd behandelt).

Jetzt habe ich Indy 10 installiert - und siehe da - der Fortschrittsbalken funktioniert nur mehr beim Download. Beim Upload - welche ja dieselben Ereignisse (OnWork, etc.) verwenden, passiert folgendes:

Sofort nach dem Start der Put-Routine für Upload wird auch das OnWorkBegin-Ereignis abgearbeitet - Richtig.
Das nächste Ereignis ist unmittelbar darauf das OnWorkEnd-Ereignis. Das OnWork-Ereignis wird beim Upload überhaupt nicht verwendet und dadurch funktioniert die ganze Sache auch nicht.

mfg
Herbert

[Luckie]

Du willst uns einfach keinen Code zeigen von den betreffenden Ereignissen oder? Deswegen mein letzter Versuch dir durch raten zu helfen: Aktualisierst du auch die Fortschrittsanzeige in den entsprechenden Ereignissen?

Zitat:

Zitat von hsbc

Das OnWork-Ereignis wird beim Upload überhaupt nicht verwendet und dadurch funktioniert die ganze Sache auch nicht.

Hast du das Ereigniss im Code auch im OI der Komponente zugewiesen?

[hsbc]

Hallo Luckie,

hier die 3 Routinen:

Delphi-Quellcode:

procedure TF_Test.IdFTP1Work(Sender: TObject; AWorkMode: TWorkMode;
  const AWorkCount: Integer);
begin
  Application.ProcessMessages;
  ProgressBar.Position := AWorkCount;
  ProgressBar.Update;
end;


procedure TF_Test.IdFTP1WorkBegin(Sender: TObject;
  AWorkMode: TWorkMode; const AWorkCountMax: Integer);
begin
  ProgressBar.Max := BytesZuSenden;
end;


procedure TF_Test.IdFTP1WorkEnd(Sender: TObject; AWorkMode: TWorkMode);
begin
  ProgressBar.Position := 0;
  ProgressBar.Update;
end;

Wie gesagt: Download wird super angezeigt, beim Upload findat das Ereignis WorkBegin überhaupt nicht statt.

Selbstverständlich sind alle 3 Routinen in OI zugewiesen.

mfg
Herbert

[Meflin]

Zitat:

Zitat von hsbc

Delphi-Quellcode:

procedure TF_Test.IdFTP1WorkBegin(Sender: TObject;
  AWorkMode: TWorkMode; const AWorkCountMax: Integer);
begin
  ProgressBar.Max := BytesZuSenden;
end;

Ich würde jetzt mal spontan sagen das muss nicht BytesZuSenden sondern AWorkCountMax heissen... Ansonsten: was soll das bitteschön sein, das ByteszuSenden :?:

[DGL-luke]

Allerdings... denn OnWork muss ja nicht pro Byte feuern! Ich nehme mal an, BytesZuSenden ist die Größe seiner Datei, die er uploaden will.

[hsbc]

BytesZuSenden ist die Grösse der Datei in Bytes. Dies funktioniert beim Download einwandfrei.

Natürlich habe ich auch schon AWorkCountMax anstatt BytesZuSenden versucht, mit dem gleichen Erfolg.

Nochmals: Das Ereignis OnWork wird beim Upload überhaupt nicht ausgeführt, beim Download sehr wohl. Dies muss in Indy 10 blockiert sein, in Indy 9 hingegen funktioniert das.

Hat vielleicht jemand eine E-Mail-Adresse von irgendeinem Indy-Entwickler, damit ich dort einfach mal die Frage stellen kann, warum dies in Indy 10 nicht mehr funktioniert.

mfg
Herbert

[DGL-luke]

Schau doch mal in den Sourcecode. Du solltest anhand der Getter/Setter von OnWork das entsprechende Feld finden und einen eventuellen Aufruf. Vielleicht ist ja tatsächlich nur der Setter kaputt?! Einfach mal ein bisschen debuggen ;)

[Meflin]

Zitat:

Zitat von hsbc

Nochmals: Das Ereignis OnWork wird beim Upload überhaupt nicht ausgeführt, beim Download sehr wohl. Dies muss in Indy 10 blockiert sein, in Indy 9 hingegen funktioniert das.

Wieso bist du dir da überhaupt so sicher :stupid: ? In deinem Code-Fizelchen ist jedenfalls kein Fehler zu entdecken. Aber vielleicht kann man dir ja doch noch ein bisschen mehr entlocken. Und wenn du der festen Überzeugung bist, dass die ach so schrottreifen Indys schuld sind, warum frägst du denn dann uns :gruebel: Wir können doch auch nichts dafür :lol:

[hsbc]

@DGL-luke

Was bedeutet Getter/Setter ???

Man müsste halt wissen, wo im Quellcode der Aufruf von OnWork stattfindet, bzw. ob dieser überhaupt stattfindet.

mfg
Herbert

[Klaus01]

Aus der IdComponent (Indy 9)

Delphi-Quellcode:

property OnWork: TWorkEvent read FOnWork write FOnWork;

Hier ist FOnWork einmal der Getter und Setter.

Grüße
Klaus

[hsbc]

@Meflin

Zitat:

Zitat von Meflin

Wieso bist du dir da überhaupt so sicher

Ich bin mir deswegen sicher, weil ich probeweise in meine OnWork-Behandlungsroutine ein ShowMessage eingebaut habe und diese wird nur beim Download und nicht beim Upload angezeigt.

Zitat:

Zitat von Meflin

In deinem Code-Fizelchen ist jedenfalls kein Fehler zu entdecken. Aber vielleicht kann man dir ja doch noch ein bisschen mehr entlocken.

Du brauchst mir nur zu sagen, welche Code-Teile ich dir noch schicken soll. Aber mehr relevante Teile gibt es dazu nicht.

Zitat:

Zitat von Meflin

Und wenn du der festen Überzeugung bist, dass die ach so schrottreifen Indys schuld sind, warum frägst du denn dann uns :gruebel: Wir können doch auch nichts dafür :lol:

Das ist mir schon klar, dass ihr auch nichts dafür könnt. Meine Frage stelle ich hier in dieses Forum deswegen, weil vielleicht doch schon jemand mit Indy 10 Erfahrung gemacht hat und dasselbe Problem hatte. Im Internet selbst habe ich leider diesbezüglich keinerlei Hinweise gefunden.

Mir wäre ev. auch geholfen, wenn ich eine E-Mail-Adresse von einem Indy-Entwickler erfahren könnte. Auch hier schweigt sich die Indy-Seite zur Gänze aus.

mfg
Herbert

[DeluxXx]

Schlag mich grade mit dem Selben Problem rum

Delphi-Quellcode:

procedure TForm1.IdFTP1WorkBegin(ASender: TObject; AWorkMode: TWorkMode;
  AWorkCountMax: Integer);
begin
  ProgressBar1.Max := AWorkCountMax;
  ProgressBar1.Position := 0;
end;

und

Delphi-Quellcode:

procedure TForm1.IdFTP1Work(ASender: TObject; AWorkMode: TWorkMode;
  AWorkCount: Integer);
begin
  //Aktualisieren der Fortschrittsanzeige:
  ProgressBar1.Position := AWorkCount;
end;

Upload Funktioniert aber eben die progressbar nicht

[Klaus01]

Könnte Ihr mal überprüfen ob die Methode InternalPut aus der idFTP.pas
mit diese mehr oder weniger übereinstimmt, diese ist von Indy 9:
Vielleicht hilft es ja dem Fehler auf die Schliche zu kommen.

Delphi-Quellcode:

procedure TIdFTP.InternalPut(const ACommand: string; ASource: TStream; AFromBeginning: Boolean = true);
var
  LIP: string;
  LPort: Integer;
  LResponse: Integer;
begin
  DoStatus(ftpTransfer, [RSFTPStatusStartTransfer]); try
    if FPassive then begin
      SendPassive(LIP, LPort);
      WriteLn(ACommand);
      FDataChannel := TIdTCPClient.Create(nil);
      with TIdTCPClient(FDataChannel) do try
        if (Self.IOHandler is TIdIOHandlerSocket) then begin
          if not assigned(IOHandler) then begin
            IOHandler:=TIdIOHandlerSocket.create(nil);
          end;
          TIdIOHandlerSocket(IOHandler).SocksInfo.Assign(TIdIOHandlerSocket(Self.IOHandler).SocksInfo);
          TIdIOHandlerSocket(IOHandler).SocksInfo.IOHandler:=IOHandler;
        end;
        InitDataChannel;
        Host := LIP;
        Port := LPort;
        Connect;
        try
          Self.GetResponse([110, 125, 150]);
          try
            WriteStream(ASource, {false}AFromBeginning);
          except
            on E: EIdSocketError do begin
              // If 10038 - abort was called. Server will return 225
              if E.LastError <> 10038 then begin
                raise;
              end;
            end;
          end;
        finally Disconnect; end;
      finally FDataChannel.IOHandler.free; FDataChannel.IOHandler:=nil; FreeAndNil(FDataChannel); end;
    end else begin
      FDataChannel := TIdSimpleServer.Create(nil); try
        with TIdSimpleServer(FDataChannel) do begin
          InitDataChannel;
          BoundIP := (Self.IOHandler as TIdIOHandlerSocket).Binding.IP;
          BoundPort := Self.DataPort;
          BoundPortMin := Self.DataPortMin;
          BoundPortMax := Self.DataPortMax;
          BeginListen;
          SendPort(Binding);
          Self.SendCmd(ACommand, [125, 150]);
          Listen;
          WriteStream(ASource, AFromBeginning);
        end;
      finally FreeAndNil(FDataChannel); end;
    end;
  finally
    DoStatus(ftpReady, [RSFTPStatusDoneTransfer]);
  end;
  // 226 = download successful, 225 = Abort successful}
  LResponse := GetResponse([225, 226, 250, 426, 450]);
  if (LResponse = 426) or (LResponse = 450) then begin
    // some servers respond with 226 on ABOR
    GetResponse([226, 225]);
    DoStatus(ftpAborted, [RSFTPStatusAbortTransfer]);
  end;
end;

procedure TIdFTP.InitDataChannel;
begin
  FDataChannel.SendBufferSize := SendBufferSize;
  FDataChannel.RecvBufferSize := RecvBufferSize;
  FDataChannel.OnWork := OnWork;
  FDataChannel.OnWorkBegin := OnWorkBegin;
  FDataChannel.OnWorkEnd := OnWorkEnd;
end;

Grüße
Klaus

[edit] habe gerade festgestellt, daß dies hier nicht die große Hilfe ist, da idFTP wohl sehr große
Veränderungen erfahren hat. [/edit]

[DeluxXx]

Hat jmd zufällig ein Tool zum Vergleichen von 2 Source Codes =P

Delphi-Quellcode:

procedure TIdFTP.InternalPut(const ACommand: string; ASource: TIdStream; AFromBeginning: Boolean = true);
var
  LIP: string;
  LPort: Integer;
  LPasvCl : TIdTCPClient;
  LPortSv : TIdSimpleServer;


begin
  FAbortFlag.Value := False;
  //for SSL FXP, we have to do it here because there is no command were a client
  //submits data through a data port where the SSCN setting is ignored.
  ClearSSCN;
  DoStatus(ftpTransfer, [RSFTPStatusStartTransfer]);
  try
    if FPassive then begin
      SendPret(ACommand);
      if FUsingExtDataPort then begin
        SendEPassive(LIP, LPort);
      end else begin
        SendPassive(LIP, LPort);
      end;
      IOHandler.WriteLn(ACommand);
      FDataChannel := TIdTCPClient.Create(nil);
      LPasvCl := TIdTCPClient(FDataChannel);
      try
        InitDataChannel;
        LPasvCl.Host := LIP;
        LPasvCl.Port := LPort;
        if Assigned(FOnDataChannelCreate) then begin
          OnDataChannelCreate(self,FDataChannel);
        end;
        LPasvCl.Connect;
        try
          Self.GetResponse([110, 125, 150]);
          try
            if  FUsingSFTP and (FDataPortProtection = ftpdpsPrivate) then begin
               TIdSSLIOHandlerSocketBase(FDataChannel.IOHandler).Passthrough := False;
            end;
            if FCurrentTransferMode<>dmDeflate then begin
              if AFromBeginning then begin
                FDataChannel.IOHandler.Write(ASource,0, false);  // from beginning
              end else begin
                FDataChannel.IOHandler.Write(ASource,-1, false); // from current position
              end;
            end else begin
              FCompressor.CompressFTPToIO(ASource,FDataChannel.IOHandler,FZLibCompressionLevel,FZLibWindowBits,FZLibMemLevel, FZLibStratagy);
            end;
          except
            on E: EIdSocketError do
            begin
              // If 10038 - abort was called. Server will return 225
              if E.LastError <> 10038 then begin
                raise;
              end;
            end;
          end;
        finally
          LPasvCl.Disconnect;
        end;
      finally
        FinalizeDataOperation;
      end;
    end else begin
      FDataChannel := TIdSimpleServer.Create(nil);
      LPortSv := TIdSimpleServer(FDataChannel);
      try
        InitDataChannel;

        LPortSv.BoundIP := (Self.IOHandler as TIdIOHandlerSocket).Binding.IP;
        LPortSv.BoundPort := FDataPort;
        LPortSv.BoundPortMin := FDataPortMin;
        LPortSv.BoundPortMax := FDataPortMax;

        if Assigned(FOnDataChannelCreate) then begin
          OnDataChannelCreate(Self, FDataChannel);
        end;

        LPortSv.BeginListen;
        if FUsingExtDataPort then begin
          SendEPort(LPortSv.Binding);
        end else begin
          SendPort(LPortSv.Binding);
        end;
        Self.SendCmd(ACommand, [125, 150]);

        LPortSv.Listen;
        if FUsingSFTP and (FDataPortProtection = ftpdpsPrivate) then begin
          TIdSSLIOHandlerSocketBase(FDataChannel.IOHandler).PassThrough := False;
        end;

        if FCurrentTransferMode<>dmDeflate then begin
          if AFromBeginning then begin
            FDataChannel.IOHandler.Write(ASource,0, false);  // from beginning
          end else begin
            FDataChannel.IOHandler.Write(ASource,-1, false); // from current position
          end;
        end else begin
          FCompressor.CompressFTPToIO(ASource,FDataChannel.IOHandler,FZLibCompressionLevel,FZLibWindowBits,FZLibMemLevel, FZLibStratagy);
        end;
      finally
         FinalizeDataOperation;
      end;
    end;
  except
    //Note that you are likely to get an exception you abort a transfer
    //hopefully, this will make things work better.
    on E: EIdConnClosedGracefully do
    begin
      if not (E is EIdConnClosedGracefully) then
      begin
        raise;
      end;
    end;
  end;

{ commented out because we might need to revert back to this
  if new code fails.
  if (LResponse = 426) or (LResponse = 450) then
  begin
    // some servers respond with 226 on ABOR
    GetResponse([226, 225]);
    DoStatus(ftpAborted, [RSFTPStatusAbortTransfer]);
  end;
  }
end;

[DGL-luke]

Naja, FOnWork steht da jedenfalls nicht drin. Schlecht.

[Klaus01]

Muß auch nicht, ich denke das Event sollte in diesem Methodenaufruf
ausgelöst werden, bzw. OnWork gesetzt werden:

Delphi-Quellcode:

FDataChannel.IOHandler.Write(ASource,0, false);  // from beginning

Grüße
Klaus

[hsbc]

Hallo allerseits,

Ich habe in meiner Application im OnCreate Ereignis gleich folgendes gesetzt:

Delphi-Quellcode:

  IdFTP1.IOHandler.Intercept := IdLogEvent1.Intercept;
  IdFTP1.IOHandler.OnWork := IdFTP1.OnWork;
  IdFTP1.IOHandler.OnWorkBegin := IdFTP1.OnWorkBegin;
  IdFTP1.IOHandler.OnWorkEnd := IdFTP1.OnWorkEnd;
  IdFTP1.IOHandler.OnStatus := IdFTP1.OnStatus;

Das funktioniert auch soweit.

Jetzt bin ich glaube ich einen Schritt weiter gekommen:

Im QuellCode des IOHandlers habe ich gesehen, dass das DoWork nur beim WriteDirect gesetzt wird, nicht aber beim normalen Write(über Puffer). Ich habe im QuellCode mal probeweise das DoWork eingefügt und siehe da, der Fortschrittsbalken bewegt sich (allerdings arbeitet er hier die gesamte Dateilänge ab und erst nachher erfolgt das Übertragen). Aber immerhin, es tut sich mal was.

Werde jetzt mal die Routinen - wie DG-luke und Klaus01 beschrieben ebenfalls näher untersuchen.

mfg
Herbert

[hsbc]

Mein Fortschrittsbalken funktioniert nun auch beim Upload !!! :firejump:

Aber nicht zu früh freuen - es ist immer noch ein Provisorim. Der Fehler liegt in der Pufferung beim Senden. Hier wird das DoWork nicht aufgerufen. Ich habe mir bis jetzt einfach so geholfen, dass ich den Upload ohne Pufferung durchführe. Hierzu habe ich den QuellCode folgendermassen geändert:

Änderung im TIdIOHandler:

procedure TiDIOHandler.Write(AStream: TIdStream; ASize: Int64 = 0; AWriteByteCount: boolean = FALSE);
begin
...
...
...
nach Zeile Nr. 1233, wo steht: LBufferingStarted := not WriteBufferingActive;

habe ich einfach die Zeile:

LBufferingStarted := false

eingefügt.

So funktioniert mal alles, wie es soll. Ich werde aber noch weitersuchen, wo in der Pufferung der Aufruf für DoWork fehlt.

mfg
Herbert

[DeluxXx]

Hm wo befindet sich denn die TIdIOHandler datei genau ?
Thx

[Klaus01]

Das ist ein Auszug aus IdIOHandler vom letzen Snapshot von Indy 10.
Wie man sieht ist dort das buffering auskommentiert.
Herbert hat das ja auf andere Weise gelöst.

Delphi-Quellcode:

procedure TIdIOHandler.Write(AStream: TIdStream; ASize: Int64 = 0;
  AWriteByteCount: Boolean = FALSE);
var
  LBuffer: TIdBytes;
  LBufSize: Integer;
  // LBufferingStarted: Boolean;
begin
  if ASize < 0 then begin //"-1" All form current position
    LBufSize := AStream.Position;
    ASize := AStream.Size;
    //todo1 is this step required?
    AStream.Position := LBufSize;
    ASize := ASize - LBufSize;
  end
  else if ASize = 0 then begin //"0" ALL
    ASize := AStream.Size;
    AStream.Position := 0;
  end;

  //else ">0" ACount bytes
  EIdIOHandlerRequiresLargeStream.IfTrue((ASize > High(Integer)) and (not LargeStream));

  // RLebeau 3/19/2006: DO NOT ENABLE WRITE BUFFERING IN THIS METHOD!
  //
  // When sending large streams, especially with LargeStream enabled,
  // this can easily cause "Out of Memory" errors.  It is the caller's
  // responsibility to enable/disable write buffering as needed before
  // calling one of the Write() methods.
  //
  // Also, forcing write buffering in this method is having major
  // impacts on TIdFTP, TIdFTPServer, and TIdHTTPServer.

  {
  LBufferingStarted := not WriteBufferingActive;
  LBufferingStarted := False;

  if LBufferingStarted then begin
    WriteBufferOpen;
  end;
  }

  //try
    if AWriteByteCount then begin
      if LargeStream then begin
         Write(ASize);
      end else begin
         Write(Integer(ASize));
      end;
    end;

    BeginWork(wmWrite, ASize);
    try
      while ASize > 0 do begin
        SetLength(LBuffer, FSendBufferSize); //BGO: bad for speed
        LBufSize := Min(ASize, FSendBufferSize);
        // Do not use ReadBuffer. Some source streams are real time and will not
        // return as much data as we request. Kind of like recv()
        // NOTE: We use .Size - size must be supported even if real time
        LBufSize := TIdStreamHelper.ReadBytes(AStream, LBuffer, LBufSize);
        if LBufSize = 0 then begin
          raise EIdNoDataToRead.Create(RSIdNoDataToRead);
        end;
        SetLength(LBuffer, LBufSize);
        Write(LBuffer);
        // RLebeau: DoWork() is called in TIdIOHandlerStack.WriteDirect()  <---------------
        //DoWork(wmWrite, LBufSize);   <--- vielleicht wenn es nicht laufen sollte, hier doWork wieder aktivieren.
        Dec(ASize, LBufSize);
      end;
    finally
      EndWork(wmWrite);
      LBuffer := nil;
    end;
  {
    if LBufferingStarted then begin
      WriteBufferClose;
    end;
  except
    if LBufferingStarted then begin
      WriteBufferCancel;
    end;
    raise;
  end;
  }
end;

Nun der Auszug aus idIOHandlerStack:

Delphi-Quellcode:

procedure TIdIOHandlerStack.WriteDirect(var ABuffer: TIdBytes);
var
  LCount: Integer;
  LPos: Integer;
  LSize: Integer;
begin
  inherited WriteDirect(ABuffer);

  Assert(Binding<>nil);

  LSize := Length(ABuffer);
  LPos := 0;
  repeat
    LCount := Binding.Send(ABuffer, LPos, LSize - LPos);
    // TODO - Have a AntiFreeze param which allows the send to be split up so that process
    // can be called more. Maybe a prop of the connection, MaxSendSize?
    TIdAntiFreezeBase.DoProcess(False);
    FClosedGracefully := LCount = 0;

    // Check if other side disconnected
    CheckForDisconnect;
    DoWork(wmWrite, LCount);
    Inc(LPos, LCount);
  until LPos >= LSize;
end;

Wo der aufgerufen wird ist mir aber nicht ersichtlich.

Grüße
Klaus

[DeluxXx]

Hm also ich find die Stelle im Code nicht koennt mir jmd helfen oder hab ich die falsche Datei ?

[Klaus01]

Hallo,

Du hast Die Version 10.0.52 inzwischen wurde
idIOHandler geändert.
Die letzte Version findest Du hier -> http://www.indyproject.org/Sockets/D...apshot.en.aspx
Wie der Name schon sagt eine Entwicklungs Snapshot.

Grüße
Klaus

[DeluxXx]

Danke
aber anscheinend is der Mirror offline
NOTE: This mirror is currently offline due to misuse. It will be reopened shortly.
:cry:
muss ich wohl warten

[Klaus01]

Oder auf diesen Mirror schauen: http://indy.fulgan.com/ZIP/

Grüße
Klaus

[DeluxXx]

Danke =)

[hoika]

Hallo,

ich würde die 3 Events noch einmal komplett zuweisen.
also Löschen des Codes (verschieben ;))
und nochmal erzeugen.

Nach dem Blog sind ja jetzt einige Integer zu Int64 mutiert.

Was passiert eigentlich, wenn du breakpoints auf die
3 Events setzt, sind die rot oder grün (deaktiviert).


Heiko

[DeluxXx]

Hm es funktioniert immer noch nicht, auch nachdem Indy auf dem neusten Stand ist. Habe im Code nachgeguckt und es ist auskommentiert. OnWork,OnWorkBegin und OnStatus werden aber nicht aufgerufen :wall:
Der Upload mit idftp funktioniert und die Breakpoints sind rot hilft aber auch nix er kommt ja nie bis zum breakpoint
:firejump:

[Klaus01]

Was passiert denn wenn Du in der Write Methode bei onWork die Kommentierung wieder entfernst?

Geht es dann?

Delphi-Quellcode:

procedure TIdIOHandler.Write(AStream: TIdStream; ASize: Int64 = 0;
  AWriteByteCount: Boolean = FALSE);
var
  LBuffer: TIdBytes;
  LBufSize: Integer;
  // LBufferingStarted: Boolean;
begin
  if ASize < 0 then begin //"-1" All form current position
    LBufSize := AStream.Position;
    ASize := AStream.Size;
    //todo1 is this step required?
    AStream.Position := LBufSize;
    ASize := ASize - LBufSize;
  end
  else if ASize = 0 then begin //"0" ALL
    ASize := AStream.Size;
    AStream.Position := 0;
  end;

  //else ">0" ACount bytes
  EIdIOHandlerRequiresLargeStream.IfTrue((ASize > High(Integer)) and (not LargeStream));

  // RLebeau 3/19/2006: DO NOT ENABLE WRITE BUFFERING IN THIS METHOD!
  //
  // When sending large streams, especially with LargeStream enabled,
  // this can easily cause "Out of Memory" errors.  It is the caller's
  // responsibility to enable/disable write buffering as needed before
  // calling one of the Write() methods.
  //
  // Also, forcing write buffering in this method is having major
  // impacts on TIdFTP, TIdFTPServer, and TIdHTTPServer.

  {
  LBufferingStarted := not WriteBufferingActive;
  LBufferingStarted := False;

  if LBufferingStarted then begin
    WriteBufferOpen;
  end;
  }

  //try
    if AWriteByteCount then begin
      if LargeStream then begin
         Write(ASize);
      end else begin
         Write(Integer(ASize));
      end;
    end;

    BeginWork(wmWrite, ASize);
    try
      while ASize > 0 do begin
        SetLength(LBuffer, FSendBufferSize); //BGO: bad for speed
        LBufSize := Min(ASize, FSendBufferSize);
        // Do not use ReadBuffer. Some source streams are real time and will not
        // return as much data as we request. Kind of like recv()
        // NOTE: We use .Size - size must be supported even if real time
        LBufSize := TIdStreamHelper.ReadBytes(AStream, LBuffer, LBufSize);
        if LBufSize = 0 then begin
          raise EIdNoDataToRead.Create(RSIdNoDataToRead);
        end;
        SetLength(LBuffer, LBufSize);
        Write(LBuffer);
        // RLebeau: DoWork() is called in TIdIOHandlerStack.WriteDirect()  <---------------

        DoWork(wmWrite, LBufSize);   <--- vielleicht wenn es nicht laufen sollte, hier doWork wieder aktivieren.

        Dec(ASize, LBufSize);
      end;
    finally
      EndWork(wmWrite);
      LBuffer := nil;
    end;
  {
    if LBufferingStarted then begin
      WriteBufferClose;
    end;
  except
    if LBufferingStarted then begin
      WriteBufferCancel;
    end;
    raise;
  end;
  }
end;

[DeluxXx]

hm es funktioniert immer noch nicht Onwork OnStatus Onworkbegin werden nicht aufgerufen

[Klaus01]

Delphi-Quellcode:

var 
  LBuffer: TIdBytes; 
  LBufSize: Integer; 
  // LBufferingStarted: Boolean; 
begin   <--- wenn Du hier einen Breakpoint setzt und durch den Code stepst

was passiert denn dann?

Grüße
Klaus

[fragile]

Hi,
sitze hier auhc grade an dem Problem - wurde das in der Zwischenzeit in IdFTP behoben ? Ist immerhin 2 Jahre her ;)...

Update: Habs grad ausprobiert mit einer Progressbar und OnWorkBegin, OnWork und dem OnAfterPut Event zum Updaten der Verzeichnissicht nach dem Upload ->
funzt einwandfrei bei mir !