Event bei Minutenwechsel der Windows-Uhr?

[AuronTLG]

Hallo,

ich bin gerade dabei, in einem Programm eine Art Alarm-Funktion zu verbessern.
Momentan läuft die noch so, dass mit einem minütlichen Timer überprüft wird, ob der eingestellte Zeitpunkt gekommen ist.
Mich würde interessieren, ob es möglich wäre, statt des Timers den notwendigen Code immer dann auszuführen, wenn die Windows-Uhr ihren Minutenwechsel macht, damit es auch wirklich passend zur Systemzeit kommt.
Ich würde erwarten, dass es dafür ein WinAPI-Event gibt, habe bisher aber noch nichts gefunden.

Deswegen mal die Frage: Weiß wer was dazu?

[himitsu]

Da Windows selber keine Messages/Notifications rausschickt, wenn die Uhr sich "normal" ändert (abgesehn bei Änderung von Datum/Uhrzeit, z.B. durch die Zeitaktualisierung aus einem Zeitserver oder bei Sommer-/Winterzeit)
Nein.

Viele lassen im Hintergrund einen Timer oder Thread laufen, welcher z.B. sekündlich tickt und bei Änderung der Minute, lösen sie dann eine Aktion aus. (oder eben zu gewissen Zeitpunkten)


Man kann einen Timer auch so starten/neustarten, dass er mit der Differenz zum gewünschten Zeitpunkt wartet,
bzw. im Zeitthread die Millisekunden bis zur nächsten Minute berechnen, dann passend ein WaitFor und nach dem Event wieder erneut die nötige Pause ausrechnen usw. (CreateEvent oder TEvent)

[Uwe Raabe]

Vermutlich muss man einen Kompromiss zwischen Genauigkeit und Aufwand finden. So kann man sich mit einem dynamischen Timer (z.B. 59 Sekunden gefolgt von bis zu 10x 100ms) ziemlich genau herantasten. Ist dann wirklich mal viel zu tun, kommt der Alarm eben ein paar Millisekunden später. Wenn es dabei lediglich um die Benachrichtigung lebender Personen mit normaler Reaktionszeit geht, sollte das nicht relevant sein.

[AuronTLG]

Alles klar, danke.
Ich hatte gehofft, es gäbe vielleicht eine simple Lösung.
Dann überlege ich mir mal, wie genau ich es haben möchte.

[Delphi.Narium]

Delphi-Quellcode:

function  CalcTimerInterval(iTimerInterval : Integer) : Integer;
Var
          dNow : Double;
begin
  // Interval setzen
  // Tagesdatum und Uhrzeit holen
  dNow := Now;
  // Den Tagesanteil holen (= Nachkommastellen).
  dNow := dNow - Trunc(dNow);
  // Rest bis Mitternacht holen.
  dNow := 1 - dNow;
  // Nachkommastellen mal Millisekunden pro Tag
  Result := Trunc(dNow * 86400000);
  // wir benötigen den Rest bis zum angegeben Interval, damit der Timer
  // zur nächsten Minute, Stunde, 0 Uhr ... aktive wird.
  Result := (Result mod Max(iTimerInterval,1));
end;

procedure Form1.Timer1Timer(Sender : TOBject);
begin
  Timer1.Enabled := false;
  // Machen, was immer zu machen ist.
  Timer1.Interval := CalcTimerInterval(60000); // für eine Minute
  Timer1.Enabled := true;
end;

Fehlertoleranz: +-/ 1 Millisekunde. Deutlich einfacher und resourcenschonender als per wiederholtem Timeraufruf mit kleinerwerdendem Intervall hoffentlich einen bestimmten Zeitpunkt möglichst genau zu treffen.

Zeit läuft in einen definierten Tempo ab.
Zeit ist berechenbar.
Per Berechnung kann man somit beliebige Zeitdifferenzen ermitteln.
Per Computer ist das nur simple Mathematik.

Als Mensch muss man, um pünklich zu sein, wiederholt auf die Uhr schauen. (Per verändertem AufDieUhrSchauIntervall möglichst pünktlich sein - und das klappt oft auch nicht wirklich richtig ;-)).

Der Computer kann die Zeitdifferenz einmal berechnen und sich per Timer drauf verlassen, dass er pünktlich ist ;-)

Und wenn zwischenzeitlich wer an der Uhr dreht und meint die Zeit verstellen zu müssen, scheitern beide (bis zum nächsten Intervall ;-))

[TomyN]

Ich würde mal in die Docu zu CreateWaitableTimer schauen, da kann man eine Absolutzeit angeben bei der der Timerevent kommt.

[Rollo62]

Bei solchen Zeit-Problemen frage ich mich immer was prinzipiell die bessere Lösung wäre, und warum:
1. Timer-Lösung
2. Thead-Lösung, s.B. mit Sleep

Vielleicht kann das hier jemant aufklären ?

Ich persönlich tendiere auch ehere zu Timern, weil das in der Regel weniger Probleme macht.

[TomyN]

Oder Thread mit Timer :-)

Gefühlsmässig halte ich Sleep für sehr unpräzise, kann es aber nicht begründen.

[dummzeuch]

Zitat:

Zitat von TomyN (Beitrag 1514042)

Ich würde mal in die Docu zu CreateWaitableTimer schauen, da kann man eine Absolutzeit angeben bei der der Timerevent kommt.

Genaugenommen setzt man die Zeit in SetWaitableTimer.

Aber Du hast Recht, das scheint mir auch die beste Lösung zu sein.

[KodeZwerg]

Zitat:

Zitat von Rollo62 (Beitrag 1514051)

Bei solchen Zeit-Problemen frage ich mich immer was prinzipiell die bessere Lösung wäre, und warum:
1. Timer-Lösung
2. Thead-Lösung, s.B. mit Sleep

Vielleicht kann das hier jemant aufklären ?

Ich persönlich tendiere auch ehere zu Timern, weil das in der Regel weniger Probleme macht.

Timer ist sehr resourcenschonend also würde ich als WinAPI-Fan einem Thread in diesem Fall bevorziehen.
Sleep in einem Thread ist auch okay, wenn man Sleep wie in Delphi.Nariums Beispiel anpasst auch präzise genug (wenn es sich nicht um ein paar verlorene millisekunden geht...)

Zitat:

Zitat von TomyN (Beitrag 1514054)

Oder Thread mit Timer

Thread mit Timer, noch nie probiert, kannst Du da mal ein Beispiel für machen wie das funktioniert?

Auch noch zu erwähnen, was man machen kann wenn es nicht total ultra präzise sein muss...
WaitForSingleObject() bzw WaitForMultipleObjects() bzw per Event MsgWaitForMultipleObjects() sofern man sich in die WinAPI begeben möchte 8-)

[Rollo62]

Zitat:

Zitat von TomyN (Beitrag 1514054)

Oder Thread mit Timer :-)

Gefühlsmässig halte ich Sleep für sehr unpräzise, kann es aber nicht begründen.

Der Timer ist aber auch "unpräzise", eine Thread Lösung hätte da meiner Meinung nach mehr Möglichkeiten.

Jednfalls sehe ich für meine Projekte die Präzision sowieso nicht als kritisch an, in 90% aller Fälle reicht eine sehr moderate Präzision (1-2 Sek) aus, manchmal kann eine leichte Prozessänderung die Präzisionsanforderung dahingehend reduzieren.
Hohe Zeitpräzision ist meistens eine Illusion :-)

Wann braucht man wirklich Präzision im 10ms Bereich, im genannten Fall jedenfalls nicht ?
Trotzdem wäre es gut mal eine stabile Lösung für echte ms/us Präzision in der Werkzeugkiste zu haben ( also quasi Echtzeitanforderungen ).
In der Praxis macht einem da aber sowieso schon das Betriebssystem einen Strich durch de Rechnung, was wohl mal locker sporadische Aussetzer im Sekundenbereich oder mehr haben kann, auch wenn es ansonsten im System-Tick bei ca. 10ms einigermaßen stabil ist.

@KodeZwerg
Ja Timer sind OK für mich in 90% der Fälle, ich habe nur immer ein schlechtes Bauchgefühl noch aus den Zeiten als es mal begrenzte Anzahl an System-Timern gab.
Ich glaube aber die Realität heute ist, dass es kein Problem sein sollte mal hier und da einen Timer einzusetzen,
trotzdem gehe ich noch immer sehr sparsam damit um.

[Michael II]

Zitat:

Zitat von Rollo62 (Beitrag 1514057)

In der Praxis macht einem da aber sowieso schon das Betriebssystem einen Strich durch de Rechnung, was wohl mal locker sporadische Aussetzer im Sekundenbereich oder mehr haben kann,

...wäre zum Beispiel bei einem "MIDI Sequencer" nicht gut. Was du suchst sind Multimedia Timer.

Die Zeit darfst du dann auch nicht über now/GetSystemTime abgreifen, da dieser Wert nur alle paar ms aktualisiert wird (auf vielen Systemen nicht mal in regelmässigen Abständen).

Wenn du auf 100ns genau die Systemzeit abgreifen willst, geht das über GetSystemTimePreciseAsFileTime; für eine Auflösung im ms Bereich also so:

Delphi-Quellcode:

    procedure GetSystemTimeFT( var st : TSystemTime );
    var tf : TFileTime;
    begin
      GetSystemTimePreciseAsFileTime ( tf );
      FileTimeToSystemTime( tf, st );
    end;

Oder... ...selber schreiben (PerformanceCounter, Atomzeitserver).

Aber für die gestellte Aufgabe ist das alles viel zu viel.

[venice2]

Ich verwende für sowas SetWaitableTimer in Verbindung mit Thread und WaitForSingleObject.
Aber man kann es auch übertreiben.

Delphi-Quellcode:

function MySetWaitableTimer(hTimer: THandle;
                            var lpDueTime: TLargeInteger;
                            lPeriod: longint;
                            pfnCompletionRoutine: TFNTimerAPCRoutine;
                            lpArgToCompletionRoutine: Pointer;
                            fResume: BOOL): BOOL;
                            stdcall; external 'kernel32.dll' name 'SetWaitableTimer';

Kleiner Ausschnitt..

Delphi-Quellcode:

constructor TVisDataThread.Create(var DataReadyMsg: HWND; var MemPointer: Pointer);
begin

  inherited Create(True);

  FDriveThreadId := 0;

  FShareMemPointer := GetBufferAddress;
  MemPointer := FShareMemPointer;
  FVisTimer := CreateWaitableTimer(nil, False, nil);
  if FVisTimer <> 0 then
  begin
    DataReadyMsg := FDataReadyMsg;
    FDelayMS := 0;
    FModuledelayMs := 0;
    FDelayMSChanged := False;
    FThreadReady := True;
  end;

end;

Delphi-Quellcode:

procedure TVisDataThread.Execute;
const
  _SECOND = 10000000;
var
  qwDueTime: Int64;
  liDueTime: _LARGE_INTEGER;
  ErrMsg: string;
begin

  if FVisTimer = 0 then
    Exit;

  // Create a negative 64-bit integer that will be used to
  // signal the timer 1/4 seconds from now.
  qwDueTime := -1 * (_SECOND div 4);

  // Copy the relative time into a LARGE_INTEGER.
  liDueTime.LowPart := DWORD(qwDueTime and $FFFFFFFF);
  liDueTime.HighPart := longint(qwDueTime shr 32);
  if MySetWaitableTimer(FVisTimer,                 // handle to a timer object
                        TLargeInteger(liDueTime), // when timer will become signaled
                        FDelayMS,                 // periodic timer interval
                        nil,                      // pointer to the completion routine
                        nil,                      // data passed to the completion routine
                        False {flag for resume state}) then
    // Following sentences are repeated every FDelayMS interval all the time from initial
    // start up to program end.
    repeat
      // We need to re-adjust timer interval according to the parameter "DelayMS" of vis plug-in.
      // (in case we exchange vis plug-ins)
      if FDelayMSChanged then
      begin
        FDelayMSChanged := False;
        CancelWaitableTimer(FVisTimer);
        MySetWaitableTimer(FVisTimer, TLargeInteger(liDueTime), FDelayMS, nil,
          nil, False);
      end;

      if WaitForSingleObject(FVisTimer, 1000 {1sec}) = WAIT_OBJECT_0 then
      begin
        DoOnVisTimer;
      end else
        Terminate;

      SuspendIfHalted;
    until Terminated
  else
  begin
    ErrMsg := SysErrorMessage(GetLastError);
    ShowErrorMsgBox(ErrMsg);
    Terminate;
  end;
end;

[himitsu]

Zitat:

nicht gut.

Hängen kann es so oder so, da hilft auch kein anderer Timer,
auch wenn Dieser um einige Millisekunden genauer arbeiten dürfte.


Hier ging es um etwas im Sekundenbereich, für menschliche Maßstäbe, wo es (meistens) garnicht so genau sein muß.
Wenn ein Rechner total augelastet/überlastet sein sollte, dann wäe es mir auch egal (hätte Verständnis dafür), wenn es hier mal 'ne Sekunde/Minute hängt.


Ja, die Frage war "gibt es schon was Fertiges?".

Antwort: nein (OK, jain)

* TimerEvent-Komponente dafür besorgen (oder bauen lassen)
* Timer öfters/regelmäßig triggern und Prüfen ob Minute voll
* Timer auf nachfolgende Minute einstellen
* Thread
* oder 200 Milliarden andere Lösungen


PS: er wollte es einfacher haben,
da ist es eh kontraproduktiv, wenn ihr es noch komplizierter macht. :zwinker:

ein TTimer mit Interval von 1000 (oder weniger, z.B. 500, 250 oder 100)

Delphi-Quellcode:

procedure TForm1.Timer1Timer(Sender: TObject);
begin
  //Label1.Caption := FormatDateTime('hh:mm:ss .zzz', Now);
  if Now < FNextEvent then
    Exit;
  FNextEvent := Trunc(Now * MinsPerDay + 1) / MinsPerDay;

  // mach irgendwas wenn die neue Minute beginnt
  Caption := TimeToStr(Now);
  Beep;
end;

Oder hab ich's übersehen und es gibt doch irgendwo ein RoundToMinute (Trunc) ?

oder

Delphi-Quellcode:

  FNextEvent := IncMinute(Now, 1);
  FNextEvent.SetSecond(0);
  FNextEvent.SetMilliSecond(0);

oder

Delphi-Quellcode:

  FNextEvent := IncMinute(RecodeDateTime(Now, RecodeLeaveFieldAsIs, RecodeLeaveFieldAsIs,
    RecodeLeaveFieldAsIs, RecodeLeaveFieldAsIs, RecodeLeaveFieldAsIs, 0, 0), 1);

oder
...

[Neumann]

Wenns nicht allzu genau sein muss, hier eine sehr simple Lösung:

Globale Variable Oldtime:tdatetime
In Onidle:

Delphi-Quellcode:

if now >= Oldtime+1/(24*60*60) then // 1 Sekunde
begin
  Oldtime:=now;
  dosomthing;
end;

Oldtime noch irgendwo initialisieren bei Programmstart

[Michael II]

Zitat:

Zitat von himitsu (Beitrag 1514087)

Zitat:

nicht gut.

Hängen kann es so oder so, da hilft auch kein anderer Timer,
auch wenn Dieser um einige Millisekunden genauer arbeiten dürfte.

Das MIDI Beispiel stammt nicht von mir sondern von m$.
Multimediatimer arbeiten nicht via Warteschlange sondern via Callbackfunktion. Das ist definitiv präziser. Da gibt's also schon einen Unterschied zwischen Timer und MMTimer.

Meine Meldung bezog sich auf Rollo62s Frage und nicht auf 1.

Dein Vorschlag einfach noch mehr Timer Events auszulösen um dann zu prüfen, ob eine Zeit erreicht ist bringt ausser Arbeit und noch mehr Stau in der Warteschlange nix.

Für die ursprüngliche Fragestellung sind die vorgeschlagenen WaitableTimers doch absolut topp: Du stellst eine Zeit ein und wirst benachrichtigt.

Die Idee von Neumann mit OnIdle ist nicht gut. Da wird u.U. von einer Minute zur nächsten millionenfach nachgefragt, ob wir bereits wieder grün leuchten sollen. OnIdle solltest du gar nicht nutzen... ausser vielleicht für handgestrickte Videogames (Ausgabe von Bildern unter Volllast) oder wenn du mit Threads nix am Hut hast und gewisse Aufgaben dann erledigen lassen willst, wenn grad sonst nix läuft.

Ich bin dann mal weg.

[himitsu]

Zitat:

Zitat von Michael II (Beitrag 1514116)

Zitat:

Zitat von himitsu (Beitrag 1514087)

Zitat:

nicht gut.

Hängen kann es so oder so, da hilft auch kein anderer Timer,
auch wenn Dieser um einige Millisekunden genauer arbeiten dürfte.

Das ist egal.
Da er etwas in der GUI machen will, muß er zwangsläufig Synchronisieren.

Ja, wenn man ausschließlich im Hintergrund (Thread) arbeitet, da ist der Hauptthread egal,
aber einem ContextSwitch entkommst du (normalerweise) dennoch nicht so leicht.