Auf eine bestimmte Uhrzeit warten (war: F98)
-
Hallo,
was hälst du einem Thread, der in einem festzulegenden Interval die Uhrzeit liest und dann die Funktion startet z.B. über ein Ereignis. Mit der Klasse TEvent (C++ Builder) stehen dir dann die nachstehenden Flags für einen automatisierten Durchlauf zur VerfügungwrSignaled Das Signal für das Ereignisobjekt wurde gesetzt.
wrTimeout Die im Parameter Timeout angegebene Zeitspanne ist verstrichen, ohne daß das Signal gesetzt wurde.
wrAbandoned Das Ereignisobjekt wurde gelöscht, bevor das Timeout-Intervall verstrichen ist.
wrError Beim Warten ist ein Fehler aufgetreten. Überprüfen Sie die Eigenschaft LastError auf einen Fehlercode, der nähere Informationen enthält.Evi48
-
Original erstellt von evi48:
**Hallo,
was hälst du einem Thread, der in einem festzulegenden Interval die Uhrzeit liest und dann die Funktion startet z.B. über ein Ereignis.
**nicht notwendig. Nimm ein Timer und berechne den Intervall.
nimm die aktuelle Uhrzeit ( Siehe Time() oder Date() ) und ziehe diese von der Zieluhrzeit ab. Rechne die Differenz in Sekunden um und setzt den Intervall.
Fertig
-
Original erstellt von AndreasW:
Rechne die Differenz in Sekunden um und setzt den Intervall.Nur dumm, wenn sich dann vor Ablauf des Intervalls aus irgendeinem Grund die Uhrzeit des Rechners ändert.
-
Das mit den Threads ist eine interessante Sache. Nur denke ich ist das für das Problem zu komplex.
@AndreasW & Jansen
Der Vorschlag von AndreasW ist ziemlich clever. Eigentlich wollte ich es so machen: Wenn der Abstand akt_Zeit-Ziel_Zeit > 1h ist, dann wird das TimerIntervall auf 60000 gestellt. Je näher nun der Zeitpunkt des Ereignisses rückt, um so weiter runter wird nun das Timerintervall gestellt (min 1000).
[ Dieser Beitrag wurde am 05.06.2003 um 09:26 Uhr von F98 editiert. ]
-
Ja und? Wenn der User zB. merkt, dass seine Uhr schon ewig um zwei Stunden nachgeht und das korrigiert, während dein Timer läuft, dann ist deine ganze Berechnung für den A...
Es hilft nichts, wenn du sichergehen willst musst du jede Sekunde (oder entsprechend der von dir akzeptierten Toleranz) die aktuelle Systemzeit prüfen.
-
wenn jemand sowas macht, war ich für unwahrscheinlich halte, kann man immer noch auf WM_TIMECHANGE reagieren und Jansens Sorgen somit abbauen...
-
Warum denn alles so "umständlich" ? Was spricht dagegen den Timerintervall auf 1 oder 1/2 Sekunde zu stellen ? So viel Code wird im Timerevent doch wohl nicht abgehandelt, oder ?! Ich hab schon einige "Auto-Programme" gebaut. Timerintervall ca. 1 Sekunde und nebenbei auch noch eine Uhr mitlaufen lassen. Uhrzeit auf der Form links, Auslösezeit daneben (oder so ähnlich), so sieht man auf einen Blick wann es soweit sein wird
-
Original erstellt von Peter:
Warum denn alles so "umständlich" ? Was spricht dagegen den Timerintervall auf 1 oder 1/2 Sekunde zu stellenhehe, kein Wunder das wir immer bessere Computer brauchen wenn Programmierer so denken.... Diese Denkweise ist genau der Grund, warum die heutigen PC's, trotz enormer Leistungskapazität, immer noch so ineffektiv sind.
Wenn dieses Programm im Hintergrund agieren soll frist es ( zwar wenig aber doch vorhanden ) Systemressourcen, die eigentlich nicht notwendig sind.
Auch in einem Multitasking - System mit kommenden Hyperthreading brauchen Timer- Aufrufe ein paar Takte, die der PC irgendwo anders besser einsetzen könnte. An Optimierung denkt heutzutage wohl aus Bequemlichkeit wohl kaum noch jemand. Leider.
Schaut euch doch mal den C64 an, und womit der ausgekommen ist. Und die Programme waren auch nicht wesentlich schlechter als die von heute ( Verhältnismäßig und auf Stand der Dinge und auf den Zeitabschnitt gesehen).
Dagegen sind die heutigen Programme doch die reinsten Mülltonnen für Speicher und Performance. Windows selbst ist da der Klassiker..
-
hehe, kein Wunder das wir immer bessere Computer brauchen wenn Programmierer so denken....
Ich muß Dir vollkommen zustimmen, nur sollte man immer von Fall zu Fall entscheiden wie man etwas angeht. Glaub mir, ich komme aus der Zeit eines 6502 Einplatinencomputers mit sage und schreibe 4kb Hauptspeicher und einem Systemtakt von krassen 1Mhz (habe ich später verdoppelt). VC20 und C64 kamen erst viel später. Da galt es trickreich und platzsparen zu programmieren, dementsprechend sahen die Programme auch aus
(nix objektorjentiert) Nur sind heute die Rechner wesentlich fixer auf den Beinen mit unvergleichbar mehr Hauptspeicher. Der eigentliche Resourcenfresser ist Windows selber und es ist bestimmt noch lange nicht Ende der Fahnenstange. Ich frage mich in manchen Fällen ernsthaft ob es sich wirklich lohnt, Klimmzüge zu machen um das Prog z.B. sparsamer im Resourcenverbrauch zu machen oder nicht. Vor allem was könnte man sich dabei einhandeln, siehe z.B. Jansens Einwand ?!
Eigentlich dachte ich vor Jahren mal daran, gerade aus den Gesichtspunkten Resourcen und Speicherplatz sparen, Windowsprogramme nur native auf WIN-API Basis zu proggen, vielleicht sogar in Assembler. Ich hatte damals einige Programme direkt in Assembler geschrieben (unter DOS), die waren klein und sehr schnell. Aber unter Windows lohnt sich das in der Anwendungsprogrammierung wohl kaum noch, höchstens vielleich in einigen Spezialfällen. Wenn ich meine jetzigen Projekt so anschaue, wollte ich auf die Unterstützung einer Klassenbibliothek, sprich VCL, nicht mehr verzichten und die VCL ist bestimmt nicht gerade "sparsam".
Nun gut, sollte wieder etwas arbeiten, ist ja jetzt auch etwas OT
Viel Spaß weiterhin
-
-
Ich habe noch eine Idee "OnIdle" -> wird ausgelöst, wenn eine Anwendung inaktiv wird
__fastcall TfrmMain::TfrmMain(TComponent* Owner) : TForm(Owner) { Application->OnIdle = &OnIdle; } void __fastcall TfrmMain::OnIdle(TObject*, bool &done) { done = false; //hier Zeit prüfen & evtl. Aktion ausführen. }
Gibt es dagegen irgendwelche Einwände?
[ Dieser Beitrag wurde am 11.06.2003 um 15:33 Uhr von F98 editiert. ]
-
Joah...
TTimer
Und was eure Sache mit "Nebenher noch andere Sachen zu tun" angeht:
Wie wärs mit ner If-Bedingung? *g*
z.B. im Timer selbst:
if (Time()==festgelegte_zeit)
{
// Anweisungen
}wurde hier schon ziemlich oft angedeutet *G* aber hier geht er erst rein, wenn de Bedingung erfüllt ist, vorher interessiert es dem PC nicht was er dann tun würde, sowas würde ich z.B. unter Leerlaufprozess verstehen, naja, fast *g*
[ Dieser Beitrag wurde am 11.06.2003 um 15:44 Uhr von Spieleprogrammierer editiert. ]