Timer läuft ab Mitternacht rückwärts

[MisterIXI]

Hallo zusammen,


So, zu meinem Problem:
Ich programmiere seit einiger Zeit an einem speziellen Zeitmesser herum, und bin vom hochzählen eines Timers ziemlich schnell auf das rechnen mithilfe der System zeit umgestiegen. An sich ist die Genauigkeit auf diese Weise wunderbar... Allerdings fängt der timer an, sobald die Systemuhr von 23:59 auf 00:00 umspringt, rückwärts zu laufen. Außerdem sind die ganzen Vergleiche die nebenbei ausgeführt werden natürlich auch hinfällig.

Meine Lösungsansätze bisher:
(der Timer läuft idR. weniger als 45 Minuten, aber man kann um sicherzugehen eine komplette Stunde als möglichkeit ansehen)

1. Eine Abfrage beim Starten ob die Systemzeit weniger als z.B. eine Stunde vor Mitternacht entfernt ist, und wenn das der Fall ist die ganze Berechnung zu verändern. -> ohne die Uhr des PCs zu beeinflussen (was natürlich nicht gewollt ist) sehe ich hier keinen Sinn.

2. Um 23:59:59 (am besten auf MS genau -> 23:59:59.999) Eine sekundäre Variable zuweisen, und eine neue Zeitmessung starten, auf die dann die Variable jedes mal draufgerechnet wird.



Meine Fragen:
Gibt es eine bessere Möglichkeit als die Systemzeit abzufragen um eine möglichst genaue Zeitmessung hinzubekommen?
Wie funktioniert TTime; wie weist man darauf Werte zu/wie funktionieren diese; Wie fragt man einen genauen Zeitpunkt ab... --> Habt ihr vielleicht einen Link zu einem Guten Eintrag der das ganze erklärt?
Vielleicht Ideen für bessere Lösungen des Problems?

Mein Code des Timers momentan:
Die TTime Variablen werden woanders zu weiteren Berechnungen mehrmals benutzt.

Code:

var
  T1, T2, TimeTemp : TTime;

implementation

{$R *.dfm}

procedure TForm1.Timer1Timer(Sender: TObject);

begin
Label1.Caption:=IntToStr(Zeit);
  if T1 = 0
    then T1 := Time;
  TimeTemp := MilliSecondsBetween(T1, Time) / 24 / 60 / 60 / 1000;
  Label1.Caption:=FormatDateTime('nn:ss:zzz', TimeTemp);
end;

[amigage]

Hallo,

ich würde GetTickCount() abfragen, damit bist Du Mitternachts-unabhängig :lol:

Delphi-Quellcode:

var
    start, stop, vorbei: cardinal;

implementation

{$R *.dfm}

procedure TForm1.Timer1Timer(Sender: TObject);

begin
  Label1.Caption:=IntToStr(Zeit);
  if start = 0
    then start := GetTickCount;

  stop := GetTickCount; 
  vorbei:= stop - start;  // vergangene Millisekunden
end;

Weitere Informationen dazu gibt's hier: http://delphi.about.com/od/windowssh...tstopwatch.htm

[BUG]

Oder anders: Rechne nicht mit der Uhrzeit sondern mit einer kompletten Zeitangabe (TDateTime).

[MisterIXI]

Zitat:

Zitat von amigage (Beitrag 1314246)

Hallo,

ich würde GetTickCount() abfragen, damit bist Du Mitternachts-unabhängig :lol:



Weitere Informationen dazu gibt's hier: http://delphi.about.com/od/windowssh...tstopwatch.htm

GetTickCount hatte ich anfangs, allerdings wurde der Timer ungenauer (bzw. langsamer), je stärker der PC ausgelastet war, und somit realitv unbrauchbar...

[MisterIXI]

Zitat:

Zitat von BUG (Beitrag 1314253)

Oder anders: Rechne nicht mit der Uhrzeit sondern mit einer kompletten Zeitangabe (TDateTime).

Ich hab mir das grade mal schnell angeschaut, und es scheint als wären keine Millisekunden da drin? Ich meine auf http://www.delphibasics.co.uk/RTL.as...=StrToDateTime steht zwar dass das Format dd/mm/yyyy hh:mm:ss.[millisekunden] stimmt, allerdings, wenn ich versuche Testweise einer TDateTime variable Werte zuzuweisen, dann krieg ich nur ein fehler von wegen Das ist kein Datum... Wenn ich nach den sekunden z.B. '.412' anfüge geht das genau so wenig...

Es scheint dass TDateTime zumindest theoretisch mein Problem lösen könnte, allerdings habe ich weder herausgefunden wie die Werte gespeichert/zugewiesen/abgerufen werden können, noch wie man den Abstand zweier Werte herausfindet...

[nahpets]

TDateTime sind Floatwerte, mit denen Du mit Plus und Minus... rechnen kannst.

Vor dem Komma stehen die Tage, der Nachkommaanteil repräsentiert den Tagesanteil.

Mir ist noch nicht so ganz klar geworden, was Du wirklich machen möchtest, versuch es mal hiermit:

Delphi-Quellcode:

var
  T1, T2, TimeTemp : TDateTime;

implementation

{$R *.dfm}

procedure TForm1.Timer1Timer(Sender: TObject);

begin
  Label1.Caption:=IntToStr(Zeit);
  if T1 = 0
    then T1 := Now;
  TimeTemp := Now - T1;
  Label1.Caption:=FormatDateTime('nn:ss:zzz', TimeTemp);
end;

In TimeTemp steht jetzt die Zeitdifferenz zwischen "Jetzt" und dem auf T1 zugewiesenen Zeitpunkt.

[Der schöne Günther]

Ich weiß nicht wie genau du es brauchst. Ist die Regelmäßigkeit wichtig? Dann ist ein Timer (bzw.

Delphi-Quellcode:

GetTickCount()

) nicht grade die beste Wahl, denn das ist, glaube ich, nur auf eine 64stel-Sekunde genau. Daher würde ich auch auf den Interval des Timers aufpassen, sodass es am besten glatt aufgeht.

Oder ist dir die Erfassung der genauen Zeitspanne wichtig? Dann würde ich nicht mit TDateTime arbeiten, da treten ja schon Rundungsfehler bei Millisekunden auf. Für die Erfassung eines Zeitbereichs gibt es TTimeSpan, da kannst du bequem bis auf Ticks heruntergehen:

Delphi-Quellcode:

procedure TForm1.Timer1Timer(Sender: TObject);
var
   tickCount:   DWORD;
   ticksPassed: Int64;
begin
   tickCount := WinApi.Windows.GetTickCount();
   ticksPassed := (tickCount - lastTickCount) * TTimeSpan.TicksPerMillisecond;
   timePassed := timePassed.Add( TTimeSpan.Create(ticksPassed) );

   Caption := String.Format(
      'Time passed: %.2d:%.2d:%.2d (%d ms, %d ticks)', [
      timePassed.Hours,
      timePassed.Minutes,
      timePassed.Seconds,
      timePassed.MilliSeconds,
      timePassed.Ticks
   ]);
   lastTickCount := tickCount;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
   timePassed := TTimeSpan.Zero;
   lastTickCount := Winapi.Windows.GetTickCount();
end;

Da sieht man auch ganz gut wie es mit einem Timer-Intervall von 750ms immer glautt aufgeht, mit 700 allerdings krumm wird. Kurz nachrechnen, eine 64stel-Sekunde sind 15,625 ms, jepp, geht bei 750 glatt auf, bei 700 nicht.

[MisterIXI]

Also das Ganze program ist ein sogenannter "Splitter" für Speedruns eines speziellen Spiels.
Im Prinzip eine Stopuhr...
Allerdings ist es nicht nur um eine einzelne zeitspanne zu messen sondern auch um einzelne Abschnitte mit früheren Rekorden zu Vergleichen (Beispiel: das Programm ist Für ein altes Mario Kart Spiel und wenn man eine Strecke fertig gefahren hat, drückt man einen Button. Dieser ermittelt erst die Zeit die zwischen dem letzten und diesem Drücken vergangen ist. Dann Vergleicht er diesen Wert (momentan ist die Variable die zeit in MS) mit dem in einer .ini gespeicherten Rekord. der Timer läuft in der zwischenzeit allerdings noch weiter)

Ich würde es gerne auf die Millisekunde genau und auch in Echtzeit updaten, also dass man den ganzen Timer hochticken sieht.
Ich hatte ganz am anfang das Problem, dass ich einfach einen Timer immer den TickCount hab auslesen lassen für die berechnungen. Da die zeit aber wenn möglich auf Millisekunden genau (mindestens auf sekunden genau) gemessen werden soll, waren die extrem abweichenden Werte Schwachsinn. Dass der Timer ungenau ist, war halt dadurch egal, dass die Systemzeit komplett unabhängig von der Abfragehäufigkeit/Regelmäßigkeit des Timers gearbeitet hat. Und wird auch nicht von der Auslastung von Grafikkarte,CPU, etc... beeinflusst.
Die Lösung von naphets scheint auch wunderbar zu funktionieren, ich hab zwar keinen stresstest ausgeführt, aber nach dem wechsel auf 00:00 lief die TDateTime variante weiter wie sie sollte. :thumb:

Es lief bis jetzt auch stabil mit der Time variante, und schien auch ziemlich genau. Da war ja nur das Problem mit Mitternacht. Das hätte sich mit der TDateTime variante wohl erledigt...
Und selbst wenn es nicht auf die Millisekunde genau funktioniert, ist es nicht allzu schlimm, da die schlussendlich durch die Menschliche eingabe ohnehin ungenau ist. ^^

Ich hau das ganze gleich mal von meinem kleinen Testprogramm in das eigentlich und teste ob es funktioniert.

[SMO]

Zitat:

Zitat von MisterIXI (Beitrag 1314255)

GetTickCount hatte ich anfangs, allerdings wurde der Timer ungenauer (bzw. langsamer), je stärker der PC ausgelastet war, und somit realitv unbrauchbar...

Das sollte nicht passieren. GetTickCount müsste konstant "ticken", aber wie Günther schon sagte, mit einer Auflösung/Genauigkeit von ca. 1/64s (15,625 ms).

Bei GetTickCount, sowie anderen Methoden, muss man allerdings auch an den Überlauf denken: GetTickCount liefert die Anzahl der Millisekunden seit letztem Booten des Computers, wenn der also länger als ca. 49,7 Tage am Stück lief, dann fängt der Wert wieder bei 0 an. Es kann also passieren, dass der Endwert eines Messintervalls kleiner ist als der Startwert!

Alternativen zu GetTickCount sind Multimedia Timer (timeGetTime) und QueryPerformanceCounter.

Die timeGetTime API ist sehr ähnlich zu GetTickCount, allerdings kann man die Auflösung via timeBeginPeriod auf bis zu 1 ms setzen. Über eine "undokumentierte" ntdll API (NtSetTimerResolution) sogar auf 0.5 ms.
Diese Funktionen (außer natürlich NtSetTimerResolution) findet man in der Standardunit MMSystem (Winapi.MMSystem).

Falls mehr Präzision gebraucht wird, bleibt nur QueryPerformanceCounter in Verbindung mit QueryPerformanceFrequency.

Neuere Delphi-Versionen haben übrigens eine System.Diagnostics Unit, in der ein TStopwatch Record zum Zeitmessen implementiert ist. Der benutzt GetTickCount, oder falls verfügbar QueryPerformanceCounter.

Zitat:

Zitat von MisterIXI (Beitrag 1314303)

Also das Ganze program ist ein sogenannter "Splitter" für Speedruns eines speziellen Spiels.
Im Prinzip eine Stopuhr...

Ich würde es gerne auf die Millisekunde genau und auch in Echtzeit updaten, also dass man den ganzen Timer hochticken sieht.

Verstehe. Ich hoffe dir ist klar, dass bei einer typischen Bildwiederholfrequenz von 60 Hz ein Zeitabschnitt 1/60 = 16,67 ms beträgt. Also auf die Millisekunde genau messen ist schon drin, jede Millisekunde die Anzeige aktualisieren wäre aber sinnlos. ;)

[Der schöne Günther]

Zitat:

Zitat von SMO (Beitrag 1314305)

Über eine "undokumentierte" ntdll API (NtSetTimerResolution) sogar auf 0.5 ms.

War das nicht der Grund weshalb Google Chrome über Monate (Jahre?) unter Windows die Laptop-Akkus schneller leergesaugt hat als jeder andere Browser?

[SMO]

Zitat:

Zitat von Der schöne Günther (Beitrag 1314308)

War das nicht der Grund weshalb Google Chrome über Monate (Jahre?) unter Windows die Laptop-Akkus schneller leergesaugt hat als jeder andere Browser?

Davon habe ich nichts gehört, aber sieht so aus als hättest du Recht. :)

Es stimmt auf jeden Fall, dass ein Erhöhen der Timergenauigkeit, sei es mit timeBeginPeriod oder NtSetTimerResolution, zu einer höheren Systemauslastung und damit zu höherem Energieverbrauch führt, steht auch im MSDN.

[Sir Rufo]

Wozu wird denn ein Timer überhaupt benötigt?

Wenn ich wissen möchte, wieviel Zeit vergangen ist zwischen dem Zeitpunkt x und y, dann berechne ich das einfach. Dazu benötige ich keinen Timer und zum Zeitpunkt der Abfrage ist der Wert zuverlässig genau.

Delphi-Quellcode:

TStopWatch = record
private
  FStartedAt, FStoppedAt: TDateTime;
  FIsStarted: Boolean;
public
  procedure Start;
  procedure Stop;
  function ElapsedTime : Double;
end;

procedure TStopWatch.Start;
begin
  FStartedAt := Now();
  FIsStarted := true;
end;

procedure TStopWatch.Stop;
begin
  FStoppedAt := Now();
  FIsRunning := False;
end;

function TStopWatch.ElapsedTime: Double;
begin
  if FIsRunning then
    Result := Now() - FStartedAt
  else
    Result := FStoppedAt - FStartedAt;
end;

[Der schöne Günther]

Er wollte doch eine live mitlaufende Anzeige auf seinem Formular haben, wie auf dem Display einer echten Stoppuhr auch. Da liegt ein Timer doch nahe.

[Sir Rufo]

Zitat:

Zitat von Der schöne Günther (Beitrag 1314311)

Er wollte doch eine live mitlaufende Anzeige auf seinem Formular haben, wie auf dem Display einer echten Stoppuhr auch. Da liegt ein Timer doch nahe.

Und? Den kann er doch auch für die Aktualisierung des Formulars nehmen - frage die StopWatch und zeige das Ergebnis.

Man zählt über einen Timer aber nicht mit, wieviel Zeit vergangen ist.

[Der schöne Günther]

Ich dachte du wolltest dem armen Kerl mit "Wozu wird denn ein Timer überhaupt benötigt?" ganz die Verwendung von Timern absprechen.

Aber er läuft ja jetzt um Mitternacht nicht mehr rückwärts, scheint ja alles in Ordnung jetzt :stupid:

[SMO]

Zitat:

Zitat von Sir Rufo (Beitrag 1314310)

Wozu wird denn ein Timer überhaupt benötigt?

Wenn ich wissen möchte, wieviel Zeit vergangen ist zwischen dem Zeitpunkt x und y, dann berechne ich das einfach. Dazu benötige ich keinen Timer und zum Zeitpunkt der Abfrage ist der Wert zuverlässig genau.

Schöne Lösung, aber rate mal, welche Auflösung/Genauigkeit sie hat. Richtig, exakt dieselbe wie timeGetTime. D.h. standardmäßig 15,625 ms, es sei denn die globale Timer-Auflösung wurde per timeBeginPeriod / NtSetTimerResolution verändert.

Übrigens: Die RAD Studio IDE setzt die Timer-Auflösung auf 1 ms! Das hat mich beim Debuggen schon mal gebissen. Hatte timeBeginPeriod(1) in meinem Programm vergessen und mich gewundert, warum es nur richtig lief wenn es aus der IDE heraus gestartet wurde, nicht allein.

Mit diesem kleinen Konsolenprogramm kann man minimale und aktuelle Auflösung der Multimedia-Timer ansehen.

[MisterIXI]

Zitat:

Zitat von SMO (Beitrag 1314305)

Verstehe. Ich hoffe dir ist klar, dass bei einer typischen Bildwiederholfrequenz von 60 Hz ein Zeitabschnitt 1/60 = 16,67 ms beträgt. Also auf die Millisekunde genau messen ist schon drin, jede Millisekunde die Anzeige aktualisieren wäre aber sinnlos. ;)

Klar :D

Aber du bringst mich noch auf eine andere Frage, wenn wir grad dabei sind:
Warum blinkt(/verschwindet kurz) ein Label ab und zu kurz, wenn es ständig durch z.B. Timer aktualisiert wird?
Das ist wahrscheinlich wieder mein Unwissen über manche Zyklen? Vielleicht trifft man bei ein paar frames vom Bildschirm die Zeit, die Delphi visuell updatet oder so? :?:
Kann man sowas lösen, in dem man einfach den "perfekten" Intervall eines Timers einstellt?
Es kann auch nur Wunschdenken sein, aber es scheint dass 17 oder 50 um einiges weniger blinkt als z.B.100...

Und die Geschichte mit TStopwatch scheint auch eine Lösung zu sein, aber die hab ich bis jetzt noch nie gesehen/benutzt... :P Die schaue ich mir defenitiv auch die Tage mal an!

[Sir Rufo]

Zitat:

Zitat von SMO (Beitrag 1314317)

Zitat:

Zitat von Sir Rufo (Beitrag 1314310)

Wozu wird denn ein Timer überhaupt benötigt?

Wenn ich wissen möchte, wieviel Zeit vergangen ist zwischen dem Zeitpunkt x und y, dann berechne ich das einfach. Dazu benötige ich keinen Timer und zum Zeitpunkt der Abfrage ist der Wert zuverlässig genau.

Schöne Lösung, aber rate mal, welche Auflösung/Genauigkeit sie hat. Richtig, exakt dieselbe wie timeGetTime. D.h. standardmäßig 15,625 ms, es sei denn die globale Timer-Auflösung wurde per timeBeginPeriod / NtSetTimerResolution verändert.

Es ging hier mehr um das Prinzip, dass man keinen Timer nimmt um eine Zeitspanne zu bestimmen, sondern man merkt sich die Startzeit und berechnet sich die Zeitspanne zwischen der gemerkten Startzeit und einem beliebigen anderen Zeitwert. Welche Zeitwertquelle man dabei verwendet ist - für das Prinzip - unerheblich, beim Vergleichen sollte es immer die Gleiche sein.

[SMO]

Zitat:

Zitat von MisterIXI (Beitrag 1314321)

Warum blinkt(/verschwindet kurz) ein Label ab und zu kurz, wenn es ständig durch z.B. Timer aktualisiert wird?
Das ist wahrscheinlich wieder mein Unwissen über manche Zyklen? Vielleicht trifft man bei ein paar frames vom Bildschirm die Zeit, die Delphi visuell updatet oder so? :?:
Kann man sowas lösen, in dem man einfach den "perfekten" Intervall eines Timers einstellt?

Wenn die Caption eines Labels geändert wird, muss es neu gezeichnet werden. Also erst mal der komplette Hintergrund wiederhergestellt werden, dann den neuen Text drüberschreiben. Wenn das ständig passiert, wird es flackern. Eine mögliche Lösung wäre Doublebuffering. Probiere mal die "DoubleBuffered" Eigenschaft des Parents des Labels auf True zu setzen (ist das Label direkt auf einer Form, dann Form.DoubleBuffered := True; ist es auf einem Panel, dann Panel.DoubleBuffered := True). Oder statt TLabel mal TStaticText benutzen.

Zitat:

Zitat von Sir Rufo (Beitrag 1314323)

Es ging hier mehr um das Prinzip, dass man keinen Timer nimmt um eine Zeitspanne zu bestimmen, sondern man merkt sich die Startzeit und berechnet sich die Zeitspanne zwischen der gemerkten Startzeit und einem beliebigen anderen Zeitwert. Welche Zeitwertquelle man dabei verwendet ist - für das Prinzip - unerheblich, beim Vergleichen sollte es immer die Gleiche sein.

Was ist ein "Timer"? TTimer? Wurde hier nicht benutzt. Windows hat diverse Counter, die periodisch aktualisiert werden, egal ob ein Programm sie nun abfrägt oder nicht. In diesem Sinne sind GetTickCount, timeGetTime und QueryPerformanceCounter alle Counter, keine "Timer".
Und wie du sagtest, das Prinzip ist genau dasselbe, ob man nun "Start/Endzeit := Now()" oder "Start/Endzeit := timeGetTime()" nimmt. Die Präzision von beidem hängt von der globalen Auflösung ab, die man beeinflussen kann. Dieser wichtige Punkt hat mir hier gefehlt.

Denn im OP wird nach einer "möglichst genauen Zeitmessung" gefragt. Dafür benutzt man am besten QueryPerformanceCounter, oder man muss die globale Auflösung erhöhen.

[nahpets]

Mal ganz naive gefragt:

Du möchtest zum Zeitpunkt X festlegen: Jetzt gehts los.
Zum Zeitpunkt Y sagst Du: Fertig.

Also merkst Du Dir bei X

Delphi-Quellcode:

Start := Now

.
Bei Y berechnest Du

Delphi-Quellcode:

Zeitspanne := Now - Start

.

In der Zwischenzeit soll Irgendwo eine Uhr laufen. Niemand kann so schnell gucken, dass er ein Zeitintervall von 1ms mitbekommt.
Wie oft soll denn die Uhrzeit aktuallisiert werden?
Sekündlich, reicht doch zum Mitgucken.

Also bauen wir was in der Art:

Delphi-Quellcode:

...
  tm.Interval := 1000; // = 1 Sekunde
//  tm.Interval :=  500; // = 1/2 Sekunde
//  tm.Interval :=  250; // = 1/4 Sekunde
...
procedure TForm1.tmTimer(Sender: TObject);
begin
  Label1.Caption := FormatDateTime('nn:ss:zzz', Now - Start);
end;

procedure TForm1.ButtonStartClick(Sender: TObject);
begin
  Start := Now;
  tm.Enabled := true;
end;

procedure TForm1.ButtonEndeClick(Sender: TObject);
begin
  Zeitspanne := Now - Start;
  tm.Enabled := False;
  Label1.Caption := FormatDateTime('nn:ss:zzz', Zeitspanne);
end;

Natürlich gibt es genauere Methoden der Zeitmessung, aber wenn die abhängig davon sind, wann jemand einen Button drückt, ist jeder Aufwand dahingehend, die Genauigkeit um eventuell eine 1/2 Millisekunde zu erhöhen, eigentlich irrelevant.
Und mit Now und der Ausgabe mit FormatDateTime ist man immernoch im Bereich von einer tausendstel Sekunde, so genau werden kaum mal Weltrekorde gemessen und hier geht es um Spiele.

[MisterIXI]

Das mit dem DoubleBuffered hat funktioniert! Ich wusste bis jetzt nicht mal dass die Property existiert.

Vielen, vielen Dank euch allen für die Hilfe! Ihr habt mir echt weitergeholfen. :-D

Und ich werde mir dann mal die Tage, wenn die Änderungen alle geklappt haben, die anderen Vorschläge anschauen. Dann weiß ich was ich nächstes mal besser machen kann. ^^

[Rollo62]

Erstens:
Sei doch froh wenn die Zeit rückwärts läuft !!
Das wünsche ich mir schon seit Jahren ...

Zweitens:
Es gibt auch TStopWatch
Ist vielleicht moderner, w.g. MultiPlattform

Rollo

[SMO]

Zitat:

Zitat von Rollo62 (Beitrag 1314477)

Es gibt auch TStopWatch
Ist vielleicht moderner, w.g. MultiPlattform

Das habe ich bereits in Nachricht #9 erwähnt. Aber wenn MisterIXI noch mit Delphi 7 unterwegs ist, dann hilft ihm das nicht.

[Rollo62]

Sorry, hab ich wohl um die Zeit überlesen.
Sollte bald mal ins Bett gehen :oops:

Rollo