Indy 10 und POP3 - Wo bleibt die Kompatibilität

[Jelly]

Ich hab mein Delphi 6 mit den Indy 10 Komponenten aufgepeppt, und bereue es schon bitter. Kann leider aus diversen Gründen nicht mehr zurück.

Also von Kompatibilität zu Indy 6 kann da ja nicht die Rede sein, aus Eigenschaften UserId wird Username usw... aber das war noch das geringste Problem.

Ich muss Mails abrufen von einem POP3 Account. Diese Mails muss ich aber anhand des Headers erst identifizieren. Ich hatte früher im Header stehen:

Code:

X-Mailer: {3B6F1A33-6F58-46C6-BA52-F7908CC0B3DF}

Indy 10 geht jetzt plötzlich hin, und liefert mir bei

Delphi-Quellcode:

N := POP3.CheckMessages ;

den Wert 0. Mit Indy 6 gings. Hab ich im X-Mailer was einfaches stehen wie TEST, so findet TIdPOP auch die Message.
Aaargh. Was soll das. Irgendwie wollt ich dies GUID im Header aber schon stehen lassen.

Das viel wichtigere Problem ist aber folgendes. Über folgende Prozedur lade ich die ganze Mail unter Indy 6 problemlos herunter:

Delphi-Quellcode:

procedure TImportWebRegistration.GetMail (Nr : string) ;
var
 intIndex : integer ;
 s : string ;
 LI : TListItem ;
 i : integer ;
begin
      i := StrToInt (Nr) ;
      if i <> -1 then begin
          IndyPOP3.Retrieve(i,FIndyMessage) ;

          for intIndex := 0 to pred(FIndyMessage.MessageParts.Count) do
          begin
              if FIndyMessage.MessageParts.Items[intIndex] is TIdText then
              begin
                s := TIdText(FIndyMessage.MessageParts.Items[intIndex]).Body.text ;
                CutoffUnImportantParts (s) ;
                FSB.BaseString := s ;
                FSB.BreakString := #13#10 ;
                FSB.BreakApart ;

                FContent.Assign (FSB.StringList) ;

                if assigned (OnImported) then OnImported (Counter{StrToInt(Nr)},Content) ;
              end
          end;

          if DeleteAfterImport then begin
             IndyPOP3.Delete(i) ;
             GetMessageIDs ;
          end ;
      end ;
end ;

Unter Indy 10 wird die for intIndex Schleife NIE durchlaufen. Warum nicht? Es ist eine ganz normale Mail die über den PHP Befehl SendMail verschickt wurde.

Also so langsam bereue ich den Umstieg auf Indy 10. Aber das löst mein Problem nun auch nicht.

[Jelly]

Also bevor hier noch andere sich über diese Indyinkompatibilitäten sich zu Tode suchen, hier jetzt mal, was ich ändern musste, damits auch mit Indy10 klappt... Also ne kurze Auflistung der Unterschiede:

Also

• 
  
  Delphi-Quellcode:

  for intIndex := 0 to pred(FIndyMessage.MessageParts.Count) do ...

  kann man bei Textmails mal getrost vergessen. Indy 10 handhabt den reinen Textpart einfach direkt unter
  
  Delphi-Quellcode:

  FIndyMessage.Body.text ;

  :wiejetzt:
• Beim Löschen von EMails wars bei Indy 6 so, dass diese sofort geschah. Die Liste der Mails, die man mittels Checkmessages erhält, geriet somit aus den Fugen. Daher musste Checkmessages nochmal aufgerufen werden, bevor mit den nächsten Mails fortgefahren konnte. Unter Indy 10 werden die Mails NICHT sofort gelöscht, sondern erst bei POP3.Disconnect.
• aus UserID wird UserName, und dies nicht nur bei TIdPOP3, sondern überall (z.B. TIdFTP...). Warum auch immer. :wall:

Naja, zumindest scheints bei mir nach Berücksichtigung der obigen Punkte wieder zu laufen. Aber stinkig auf die Indyentwickler bin ich trotzdem noch. Zumal ich nirgends ne Liste gefunden hab, wo diese Umstände vielleicht mal wenigstens erläutert würden. :twisted:

[jbg]

Zitat:

Zitat von Jelly

Aber stinkig auf die Indyentwickler bin ich trotzdem noch.

Was du dann auf keinem Fall machen darfst, ist in den Indy Quellcode zu schauen. Der sieht nämlich ganz anders aus als es bei Indy 8/9 der Fall war. Die .NET und vor allem die C# (ja richtig gelesen) Unterstützung haben eben ihre Spuren hinterlassen.

Zitat:

Zumal ich nirgends ne Liste gefunden hab, wo diese Umstände vielleicht mal wenigstens erläutert würden.

Du könntest ja eine solche Liste anfangen und dann den Indy-Entwicklern zukommen lassen. Die freuen sich sicherlich darüber.

[Jelly]

Zitat:

Zitat von jbg

Die .NET und vor allem die C# (ja richtig gelesen) Unterstützung haben eben ihre Spuren hinterlassen.

Dem war mir nicht mal bewusst. Aber ich mach die Kompos ja nicht schlecht. Und mich durch diese vielen Units zu wühlen, um die gründe zu finden, warum plötzlich mein alter Code komplett falsche Resultate lieferten, hab ich ja dann auch schlussendlich getan. Es war halt nur etwas störend.