Auf eine bestimmte Uhrzeit warten (war: F98)

Jansen

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.

F98

Das mit den Threads ist eine interessante Sache. Nur denke ich ist das für das Problem zu komplex.

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. ]

Jansen

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.

AndreasW

wenn jemand sowas macht, war ich für unwahrscheinlich halte, kann man immer noch auf WM_TIMECHANGE reagieren und Jansens Sorgen somit abbauen...

Peter

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

AndreasW

Original erstellt von Peter:
Warum denn alles so "umständlich" ? Was spricht dagegen den Timerintervall auf 1 oder 1/2 Sekunde zu stellen

hehe, 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..

Peter

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

AndreasW

F98

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. ]

Spieleprogrammierer

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. ]