Delay #2

[Jim Carrey]

Folgender Beitrag ist Delay #1 (von negaH): http://www.delphipraxis.net/6620-delay.html#post48420

Der Code wurde 2003 hinzugefügt. Ist es heute noch von Wichtigkeit bei einer Sleep-/Delay-Funktion an Resourcen zu denken oder eher nicht?
Und reicht ein Sleep heute vollkommen aus oder ist negaH's Version das Top der Dinge?

[Fritzew]

um Himmels Willen .......

Process Messages während eines Delays?
Sleep reicht wenn es denn sein muss.
Für was soll delay denn gut sein?
Ich glaube das habe ich zum letzten mal in Dos Zeiten benutzt, ist aber zu lange her:lol:

[jfheins]

Da ein Sleep sich ja aus eine definierte Zeitspanne bezieht, ist eine schnellerer CPU irrelevant für die Betrachtung.

Wenn die ein Sleep reicht, nimm das. Hat weniger Probleme bezüglich Threadsicherheit (eintrittsinvariant) und ist damit einfacher richtig zu machen.
Falls du dann ein Problem hast, dass die GUI nicht reagiert, musst du dir was überlegen. Also entweder Delay oder eine andere Ablaufsteuerung.

Der einzig "sinnvolle" Einsatz, den ich bisher hatte, war ein angezeigtes Log. Wenn man das Programm per [x] beendet wird die Netzwerkverbindung geschlossen. Durch ein Delay(500ms) konnte man noch kurz die Meldung sehen, dass alles erfolgreich beendet wurde.

[Namenloser]

Ich würde grundsätzlich Code vermeiden, der Application.ProcessMessages aufruft. Der Programmablauf kann dadurch nämlich sehr schwer nachvollziehbar bzw. unvorhersehbar werden.

Mir ist nicht ganz klar, welches Problem diese Delay-Routine eigentlich lösen soll. Ja gut, wahrscheinlich, dass die Oberfläche nicht einfriert, wenn man im Main-Thread Sleep aufruft. Nur ist die Frage: Warum sollte man im Main-Thread Sleep aufrufen? Das an sich halte ich schon für falsch. Also für mich ist das eher eine Frickel-Lösung. Lieber überlegen, wie man ohne Sleep auskommt.

[stahli]

Hier hatten wir kürzlich schon mal die Problematik von Application.Processmessages behandelt: http://www.delphipraxis.net/190294-p...alsection.html

[Jasocul]

Ein wenig OT:

Zitat:

Zitat von Namenloser (Beitrag 1352029)

Ich würde grundsätzlich Code vermeiden, der Application.ProcessMessages aufruft. Der Programmablauf kann dadurch nämlich sehr schwer nachvollziehbar bzw. unvorhersehbar werden.

Zumindest sollte man damit sehr vorsichtig sein. Für Aktualisierungen der GUI bei längeren Schleifen, kann es durchaus sinnvoll sein, um Fortschritte anzuzeigen. Man muss dann aber dafür sorgen, dass keine anderen Ereignisse das Programm beeinflussen können (was sehr aufwendig werden kann).

Zitat:

Zitat von Namenloser (Beitrag 1352029)

Mir ist nicht ganz klar, welches Problem diese Delay-Routine eigentlich lösen soll. Ja gut, wahrscheinlich, dass die Oberfläche nicht einfriert, wenn man im Main-Thread Sleep aufruft. Nur ist die Frage: Warum sollte man im Main-Thread Sleep aufrufen? Das an sich halte ich schon für falsch.

Wo steht hier, dass es eine Oberfläche/GUI gibt?
Ich habe mehrere Anwendungen, die ein Sleep nutzen, da in regelmäßigen Abständen geprüft werden muss, wie der Zustand bestimmter Verzeichnisse, bzw. Datenbank-Tabellen ist. Die Prüfung darf nur eine bestimmte Anzahl Versuche haben und es gibt mehrere verschiedene voneinander abhängige Prüfungen, die nacheinander ablaufen müssen. Eine GUI gibt es nicht und die Anwendung wird durch automatisierte Prozesse angestoßen. Es sind in der Regel Konsolen-Anwendungen aber es gibt nicht mal ein Konsolen-Fenster. Ja, man kann dafür auch Timer verwenden. Das hätte aber deutlich mehr Programmieraufwand bedeutet.

Bitte immer dran denken: Nur, weil man nicht weiß, wo etwas sinnvoll eingesetzt werden kann, heißt das nicht, dass es keine sinnvollen Einsatzgebiete dafür gibt.

[ConnorMcLeod]

Zitat:

Zitat von Jasocul (Beitrag 1352037)

Für Aktualisierungen der GUI bei längeren Schleifen, kann es durchaus sinnvoll sein, um Fortschritte anzuzeigen.

Meistens genügt ein Refresh/Repaint an der richtigen Stelle ;-)