OnIdle oder doch Timer?

[Daniel B]

Hallo,

was wäre den sinnvoller um Variablen immer wiede zu prüfen?
Nicht wie es einfacher wäre, sondern (programmtechnisch) sinnvoller!

Grüsse, Daniel

[tommie-lie]

Ich würde sagen, das kommt ganz darauf an, WAS das für Variablen sind.
Stammen sie aus einer externen Quelle (Signalgeber über serieller Anschluß oder sonstwas), und diese Quelle ändert ihr Signal höchstens einmal pro Sekunde, wäre OnIdle totaler overkill, denn vermutlich würde das mehrere hudnert Mal pro Sekunde ausgeführt, wenn man nicht gerade nebenbei spielt oder das Programm sonstige Berechnugnen macht. Da wäre ein Timer auf eben diese eine Sekunde sinnvoller.
Zusätzlich kommt es auf den Anwendungszweck an. Was hast du mit den Variablen vor? Wird der Wert irgendwo wieder ausgegeben, und das Augabemedium ist sehr Träge (Drucker), dann lohnt es sich nicht, tausende von Druckerjobs an den Drucker zu schicken, während der nichtmal das Papier eingezogen hat, also wieder Timer, der nur ab und zu mal schaut. Willst du eine sehr zeitkritische Sache machen, wie zum Beispiel ein Spiel, dann wäre es schon sinnvoller, die Variablen im OnIdle zu überorüfen, weil man dort ja normalerweise auch den restlichen verlauf des Spieles berechnet.
Ein dritter Hinweis noch: Wenn du auf extreme Gleichförmigkeit angewiesen bist, beispielsweise um eine AVI-Datei mit 25fps zu schreiben, ist ein Timer (und zwar ein asynchroner, was der Delphi-Timer glücklicherweise ist) sinnvoller, denn das OnIdle wird in unregelmäßigen Abständen aufgerufen, während man bei Gebrauch des Timers immer exakt 25 Bilder pro Sekunde in den AVI-Stream schrieben kann (vorausgesetzt, man komprimiert nicht zu stark).

[Daniel B]

Hallo,

ich erhalte irgendwann Daten von der seriellen Schnittstelle. Ich weiss nicht wann und was ankommt.
In der OnRxChar der Komponente(für die seriellen schnittstelle), schau ich mir die ganzen ankommenden Daten an und setze globale Variablen, eigentlich nur Boolean und Integer.

Jetzt muss ich eben immer wieder diese Varibalen überprüfen und aufgrund deren Werte, bestimmte Buttons auf dem Formular En- oder Disablen. Oder Label.Caption ändern.

Ich weiss nicht genau wieviel Daten ankommen, oder wie oft, aber was ich bis jetzt gesehen habe, würde ich im Timer mit etwa 100ms auskommen. Vielleicht schaffe ich es auch noch mit 200 oder 250ms. Ich muss mir erst die ganzen Daten anschauen ob die überhaupt richtig sind und was wozu gehört, das dauert auch ein weilchen da ich recht viel Bits und Bytes verarbeiten und verteilen muss. Und dann noch eben die ganzen Variablen setzen und dann erst die Variablen weiter verarbeiten.

Wobei ich eigentlich nicht über 200ms kommen möchte, weil man die Verzögerung an den Buttons ja schon fast wahrnehmen kann.

Grüsse, Daniel

[tommie-lie]

Rein rechnerisch beträgt die theoretische Zeit zwischen zwei Bits höchstens 0,00000868 Sekunden. Also nix im Millisekundenbereich.
Allerdings wird das selten erreicht und wenn man's byteweise rechnet, kommt man auf 0,000069444 Sekunden.
Aber wenn ich das richtig gelesen habe, brauchst du das Ganze doch sowieso nicht!
OnRXChar ist ein Event und wird ausgelöst, wenn ein Zeichen vom RX gelesen werden kann, richtig? Darin setzt du deine Variablen und willst diese regelmäßig per Labels usw visualisieren? Warum Änderst du die Captions und Enableds nicht IN diesem Event? Wenn du die Variablen anderweitig auch noch brauchst, kannst du ja immer noch die Variablen setzen UND deine Controls ändern.
Oder habe ich was falsch verstanden?

[Daniel B]

Hallo,

Zitat von tommie-lie:

OnRXChar ist ein Event und wird ausgelöst, wenn ein Zeichen vom RX gelesen werden kann, richtig?

So ist es.

Zitat:

Warum Änderst du die Captions und Enableds nicht IN diesem Event?

Ganz einfach. Die Komponente für die serielle Schnittstelle ist in einem Datenmodul. Dieses Datenmodul, benutze ich auch in anderen Programmen. Diese globalen Varibalen sind also in dieser extra Unit und somit kann ich von dort aus nichts im Hauptprogramm ändern. Ich weiss ja nicht was in den nächsten Programmen drin sein wird. Ich hab da meine ganzen Prozeduren, Funktionen, Records/Arrays, Konstanten und globale Variablen.
Von meinem Hauptprogramm, greife ich nur auf die ganzen sachen zu.

Grüsse, Daniel

[Luckie]

Schon mal an einen separaten Thread gedacht den du mit sleep() für eine bestimmte Zeit einfach "schlafen" schickst?

@tommie-lie:

Zitat:

Wenn du auf extreme Gleichförmigkeit angewiesen bist, beispielsweise um eine AVI-Datei mit 25fps zu schreiben, ist ein Timer (und zwar ein asynchroner, was der Delphi-Timer glücklicherweise ist) sinnvoller, denn das OnIdle wird in unregelmäßigen Abständen aufgerufen, während man bei Gebrauch des Timers immer exakt 25 Bilder pro Sekunde in den AVI-Stream schrieben kann

Also was ungenaueres gibt es ja wohl nicht als einen Timer zu benutzen (wenn es der normale Timer ist, aber den meinst du wohl).
Ein Timer schickt in einem bestimmten Intervall eine WM_TIMER-Nachricht an die Anwendung (Welche übrigens die niedrigeste Priorität im ganzen System haben.) Diese Nachrichten kommen in die Nachrichtenschlage für das Fenster, wie jede andere auch. Ist die nun voll oder das fenster mit was anderem bescdhäftigt bleibt sie so lange da liegen bis sie von der Anwendung abgeholt wird. Ist die Anwendung nun sehr beschäftigt, kann es im extrem Fall meherer Sekunden dauern bis die WM_TIMER-Nachricht abgeholt und bearbeitet wirde.

[tommie-lie]

Zitat von Luckie:

Also was ungenaueres gibt es ja wohl nicht als einen Timer zu benutzen (wenn es der normale Timer ist, aber den meinst du wohl).
Ein Timer schickt in einem bestimmten Intervall eine WM_TIMER-Nachricht an die Anwendung (Welche übrigens die niedrigeste Priorität im ganzen System haben.) Diese Nachrichten kommen in die Nachrichtenschlage für das Fenster, wie jede andere auch. Ist die nun voll oder das fenster mit was anderem bescdhäftigt bleibt sie so lange da liegen bis sie von der Anwendung abgeholt wird. Ist die Anwendung nun sehr beschäftigt, kann es im extrem Fall meherer Sekunden dauern bis die WM_TIMER-Nachricht abgeholt und bearbeitet wirde.

Hmm. Okay, überredet