Indy - TIdMessage - Encoding - Fortschrittsanzeige

[DerAndereMicha]

Hallo Zusammen,

hat einer von Euch ne Idee, wie man den Fortschritt beim Encodieren der einzelnen MessageParts beim Versand einer HTML-Mail über die TIdSMTP - Indy-Komponente mit Hilfe ner Progressbar anzeigen könnte. Die TIdMessage-Komponente stellt nämlich kein eigenes Ereignis dafür bereit (OnEncodeMessagePart oder so) und bei großen Anhängen könnte man schon denken, daß mein Programm beim Versenden hängen geblieben ist. TIdAntiFreeze hilft da auch nur bedingt.

Gruß
Micha

[nahpets]

Hallo,

bist Du sicher, dass das Problem bei TIdMessage liegt, hast Du schonmal probiert, ob die Ereignisse OnWork, OnStatus... der TIdSMTP Dir da eventuell brauchbare Fortschrittsinformationen liefern. Wie viele Anhänge und wie groß sind die? Könnte es nicht sein, dass das Versenden der Daten und der Empfang durch den Server den "Flaschenhals" ergeben?

[DerAndereMicha]

Hallo,

ich bin mir relativ sicher, da bei OnStatus als letztes "Encoding attachment" als AStatusText übergeben wird, bevor das Programm hängt.

Beispiel: E-Mail mit 3 Anhängen (50kb,700kb,2kb)

OnStatus:

...
Encoding attachment - 3 Sekunden
Encoding attachment - 34 Sekunden
Encoding attachment < 1 Sekunde
...

Mit OnWork,OnWorkBegin und OnWorkEnd habe ich es auch schon probiert, allerdings bekomme ich bei OnWorkBegin immer 0 als AWorkCountMax übergeben und kann deshalb dem Progressbar keinen korrekten Maximum-Wert zuweisen ...

Gruß
Micha

[DerAndereMicha]

Hallo nochmal,

hab noch ein wenig mit OnWork rumexperimentiert und festgestellt, daß ich durchaus beim Encodieren einen Fortschritt bekomme. Leider bezieht sich die Byte-Anzahl aber immer auf die Gesamtgröße der Mail und nicht auf die der einzelnen Teile. Mein einziges Problem ist jetzt nur noch herauszubekommen, wie groß die Gesamtmail ist - dann könnte ich die Fortschrittsanzeige realisieren. Ich habe aber bis jetzt keine Möglichkeit gefunden die Größe der Mail oder der einzelnen Messageparts auszulesen und im OnWorkBegin steht ja wie schon erwähnt als Gesamtgröße immer 0.

Gruß
Micha

[nahpets]

Hallo,

habe keine Ahnung, ob dass, was ich hier schreibe stimmt oder stimmen kann :wink:

Bei OnWorkBegin fangen wir ja mit der Arbeit an, die einzelnen Teile der Mail (Text, mehr oder weniger viele Anhänge...) werden zusammengebaut. Ist das fertig, kann die Mail versandt werden und erst zu diesem Zeitpunkt ist die Größe der Mail bekannt. Meiner Meinung nach kann bei OnWorkBegin die Größe der Mail noch nicht angegeben werden (auch wenn es den mit Defaultwert 0 belegten Parameter AWorkCountMax gibt). In den Quellen von idSMTP kann ich nichts finden, was hier einen Wert zuweist.

Wenn Du mehrere Anhänge an die Mails hängst, dann könntest Du den Fortschritt doch auch für jeden Anhang anzeigen, also bei 3 Anhängen von 1 bis 3 im Fortschrittsbalken. Zugegeben: Sind dann große Sprünge, aber eventuell mehr als nichts.

Oder Abhängig davon, wie Du das Programm geschrieben hast, im Quelltext an "markanten" Stellen den Fortschrittsbalken um eine Position weiterschieben. Das Maximalwert des Fortschrittsbalkens ist halt die Anzahl der so "gezählten" Schritte. Das ist dann sicherlich keine kontinuierliche Fortschrittsanzeige, aber halt "man sieht doch, dass es weitergeht".

Wie verändert sich denn in OnWork der Inhalt von AWorkCount, bei jeder Mail anders? Wenn nein, dann halt einmal den Maximalwert von AWorkCount merken und als Maximalwert für den Fortschrittswert nehmen und dann in OnWork den Fortschrittsbalken immer um eins weiterschieben.

Habe momentan nicht die Möglichkeit, mal ein Programm zu schreiben, um da ein sinnvolles Vorgehen auszutesten.

[shmia]

Vielleicht sollte man eher versuchen den Sourcecode von Indy zu verbessern.
Es kann/darf doch nicht sein, dass für läppische 700kb ganze 34 Sekunden für die Codierung anfällt.
Ich habe mir gerade mal die function TIdEncoderQuotedPrintable.Encode() angeschaut:
da wird Zeichen für Zeichen an einen String angehängt.
Ganz klar, dass das sehr langsam wird.
Du könntest etwas "Jugend forscht" betreiben und rausfinden in welcher Funktion so viel Zeit hängen bleibt.

[DerAndereMicha]

Der Wert in OnWork ändert sich bei jedem MessagePart anders - abhängig von dessen Größe.

z.B.

Encoding text 0 - 349
Encoding text 349 - 507
Encoding attachment 507 - 6216
Encoding attachment 6216 - 6500

usw.

Mir fehlt also nur die Gesamtgröße der Message und schon würde es funktionieren.

Ein paar Pseudo-Statusbalken kommen für mich nicht in Frage, da kann ich auch gleich die Eieruhr einblenden ;-)

Gruß
Micha

[DerAndereMicha]

Hallo Andreas,

glaubst Du wirklich, daß so eine wichtige und ständig verwendete Funktion wie das Codieren einer E-Mail in den Indy-Komponenten nicht optimiert ist? Wenn die Entwickler das schon nicht besser/schneller hinbekommen, wie soll ich das denn schaffen :-(

Gruß
Micha

[nahpets]

Hallo,

bei meiner Indyversion steht am Anfang der Methode ein wunderschöner Kommentar:

Delphi-Quellcode:

function TIdEncoderQuotedPrintable.Encode(ASrcStream: TStream; const ABytes: integer): string;
//TODO: Change this to be more efficient - dont read the whole data in ahead of time as it may
// be quite large

Ist damit die Ursache Deines Problemes hinreichend begründet? :wink:

shima hat mit seinem Kommentar absolut recht.

[DerAndereMicha]

Hallo,

aber helfen tut mir das bei meinem Problem auch nicht :-(

Das scheint auch schon ein sehr altes Problem zu sein, denn selbst 2002 wurde sich in der Delphi-Praxis anscheinend schon damit beschäftigt:

http://www.delphipraxis.net/internal...ect.php?t=1153

Edit: In meiner Indy-Version gibt's den Kommentar allerdings nicht mehr ...

Gruß
Micha