Und was passiert bei
Delphi-Quellcode:
IdMessage1.Body.Add( 'Stell Dir vor dieser Text würde hier nicht stehen, was bliebe übrig?' );
IdMessage1.Body.Add( '' );
Und was passiert, wenn man (in der
IDE) mit dem Cursor auf das Add geht und dann F1 drückt?
TStrings.Add
Ein
Application.ProcessMessages
wird in diesem Fall auch helfen, es sollte aber erwähnt werden, dass es dabei zu ungewollten Effekten kommen kann.
Somit wäre wohl dieser Code sinnvoller:
Delphi-Quellcode:
Label1.Caption := 'Zeig Dich';
Label1.Repaint; // erzwingt das Neuzeichnen von Label1
Die "korrekte" Vorgehensweise wäre allerdings den Mailversand in einen Thread auszulagern.
Dieser würde dann den jeweiligen Status an den Hauptthread übergeben und könnte dort ohne dieses ProcessMessages und Repaint gemütlich angezeigt werden.
Korrekt aus folgenden Gründen:
Wir arbeiten mit einer ereignisgesteuerten
GUI, also sollten wir zum Anzeigen auch Ereignisse verwenden, dann fühlt sich die
GUI wie zu Hause
Trennung von der
GUI und dem Programm-Code. Was nicht zur Kommunikation mit dem Benutzer benötigt wird hat im Quelltext des Formulars nix verloren
Lang laufende Code-Abschnitte blockieren die
GUI und der Benutzer hat das Gefühl die Anwendung klemmt oder ist abgestürzt. Somit sollen diese Teile in einem eigenen Thread laufen.
Jetzt kommt das große ABER:
Das ist dann von der Programmierung schon anspruchsvoller und für einen Anfänger nicht zu empfehlen.
Ich finde es aber wichtig darauf hinzuweisen, dass da noch was geht