Delay

[himitsu]

Man könnte doch bestimmt mal diese Beiden zusammenfassen (is ja das Selbe und auch noch vom Gleichen)
http://www.delphipraxis.net/96-delay-delphi.html
http://www.delphipraxis.net/2637-anw...zufrieren.html

dann entfernen und im dritten Eintrag integrieren.
http://www.delphipraxis.net/6620-delay.html

[lbccaleb]

Man könnte doch die beiden Versionen auch noch wieder kombinieren, von toms und negaH (so hat man ne Ressourcen sparende nonVCL Version):

Delphi-Quellcode:

procedure Delay(Milliseconds: Integer);
var
  Tick:  DWord;
  Event: THandle;
  Msg:   TMsg;
begin
  Event := CreateEvent(nil, False, False, nil);
  try
    Tick := GetTickCount + DWord(Milliseconds);
    while (Milliseconds > 0) and (MsgWaitForMultipleObjects(1, Event, False, Milliseconds, QS_ALLINPUT) <> WAIT_TIMEOUT) do begin;
      if PeekMessage(Msg, 0, 0, 0, PM_REMOVE) then begin;
        if Msg.message = WM_QUIT then begin;
          PostQuitMessage(Msg.wParam);
          Break;
        end;
        TranslateMessage(Msg);
        DispatchMessage(Msg);
      end;
      Milliseconds := Tick - GetTickcount;
    end;
  finally
    CloseHandle(Event);
  end;
end;

[himitsu]

Für NonVCL und bis D2007 isses so OK, aber für die VCL nicht, da dort noch mehr in der Schleife passiert und spätetens ab D2009 sollte man es für's Unicode anpassen.

[DeddyH]

Wie, Unicode? An welcher Stelle sind denn da Strings o.ä. im Spiel? :gruebel:

[himitsu]

z.B. bei den TastenCodes, oder bei Messages zum Auslesen/Senden von Text, wie WM_GETTEXT?
siehe IsWindowUnicode

[add]

Delphi-Quellcode:

procedure Delay(Milliseconds: Integer);
var
  Unicode: Boolean;
  Event: THandle;
  Tick: DWORD;
  Msg: TMsg;
begin
  Event := CreateEvent(nil, False, False, nil);
  try
    Tick := GetTickCount + DWORD(Milliseconds);
    while (Milliseconds > 0) and (MsgWaitForMultipleObjects(1, Event, False, Milliseconds, QS_ALLINPUT) <> WAIT_TIMEOUT) do begin
      if PeekMessage(Msg, 0, 0, 0, PM_NOREMOVE) then begin
        Unicode := (Msg.hwnd = 0) or IsWindowUnicode(Msg.hwnd);
        if (not Unicode and PeekMessageA(Msg, 0, 0, 0, PM_REMOVE)) or (Unicode and PeekMessageW(Msg, 0, 0, 0, PM_REMOVE)) then begin
          if Msg.message = WM_QUIT then begin
            PostQuitMessage(Msg.wParam);
            Break;
          end;
          TranslateMessage(Msg);
          if Unicode then DispatchMessageW(Msg) else DispatchMessageA(Msg);
        end;
        Milliseconds := Integer(Tick - GetTickcount);
      end;
    end;
  finally
    CloseHandle(Event);
  end;
end;

[hathor]

Ehrlich gesagt: Ich halte dieses Delay für grossen Mist!

http://support.microsoft.com/kb/172338/de
Zitat:
Das Betriebsystem stellt mehrere Zeitgeber mit verschiedenen Genauigkeitsstufen zur Verfügung:

Funktion____________Einheit_______________________ _Genauigkeit

Now, Time, Timer____Sekunden_______________________1 Sekunde
GetTickCount________Millisekunden_________________ _ca. 10 ms
TimeGetTime_________Millisekunden_________________ _ca. 10 ms
QueryPerformanceCounter_QueryPerformanceFrequency_ _gleich

Wenn Ihr System Zähler mit hoher Genauigkeit unterstützt, können Sie "QueryPerformanceCounter" und "QueryPerformanceFrequency" verwenden, um äußerst genaue Zeitmessungen durchzuführen.

----------
Warum wird in schöner Regelmäßigkeit dieser uralte Mist ausgekramt:
Bei manchen ist wohl die Zeit bei 1982 stehengeblieben!

[p80286]

Entschuldigung, warum diese dedizierte Meinung?
Da ich mit den sog. SplashScreens nicht viel am Hut habe, nicht soo fundiert, aber das scheint mir eine typische Delay-Anwendung zu sein. Vor kurzem gab es auch ein paar Beiträge zu Diensten, und da war so wie ich das verstanden habe auch Delay im Spiel.
Kann auch sein, daß ich da etwas vollkommen falsch verstanden habe, dann bitte ich um Aufklärung

Gruß
K-H

[jaenicke]

Zitat:

Zitat von hathor (Beitrag 1177406)

Warum wird in schöner Regelmäßigkeit dieser uralte Mist ausgekramt:
Bei manchen ist wohl die Zeit bei 1982 stehengeblieben!

Und was ist daran schlecht? Windows ist kein Echtzeitbetriebssystem, insofern ist mir das doch bei einem Aufruf von Delay total egal, ob die Genauigkeit ein paar Millisekunden beträgt... Wozu soll ich da unbedingt nen PerformanceCounter nehmen? :roll:

[himitsu]

Ich weiß auch nicht, was man gegen eine Genauigkeit von immerhin durchschnittlich 0,010 bis 0,016 Sekunden hat. (merkt eh kein Benutzer diese Abweichung)

[Furtbichler]

hathor hat vielleicht gestern abend ein schlechtes Bier getrunken.
Oder gar keins :stupid:

[negaH]

Zitat:

Zitat von hathor (Beitrag 1177406)

Ehrlich gesagt: Ich halte dieses Delay für grossen Mist!

http://support.microsoft.com/kb/172338/de
Zitat:
...
Wenn Ihr System Zähler mit hoher Genauigkeit unterstützt, können Sie "QueryPerformanceCounter" und "QueryPerformanceFrequency" verwenden, um äußerst genaue Zeitmessungen durchzuführen.

Jo, man macht im Mikrosekunden bis Nanosekundenbereich per QueryPeformanceCounter Messungen die durch den Betriebsystem-Tasksheduller nur mit 20 Millisekunden Genauigkeit aufgerufen werden. Das nenn ich dann idiotischen Schwachsinn.

Man hat also eine Atomuhr bei der der Beobachter nur alle +-20 Millisekunden die Zeit ablesen tut.


Gruß Hagen

[Furtbichler]

Das kommt auf die Implementierung an. Mit QPC kann ich wieder nanosekundenlang warten. Ok, blockierend, aber dafür extremstens(!) genauestens(!!1!EINS)

Ich lass mir doch mein Delay des 21.Jahrhunderts nicht durch Abarbeiten der MSQ ad absurdum führen.

[himitsu]

Programme laufen nicht durchgehend.
Sie werden über den Task Scheduler immer mal wieder angehalten, bzw. sie bekommen nur abechselnd ein paar Millisekunden lang Rechenzeit.
Wenn Windows das Programm kurz vor dem Messen schlafen legt, dann kann man die berechnete Pause so klein machen, wie man will ... die Messung geschieht erst bei der nächsten Bearbeitung und das kann unterschiedlich lang mehrere Millisekunden dauern, je nach Systemauslastung und Priorisierung.

Auch braucht das Verarbeiten der Messages (egal ob NonVCL oder über ProcessMessages) auch seine Zeit, sodaß man die Schleife sowieso nicht immer ganz geneu abbrechen kann.

[negaH]

Zitat:

Zitat von Furtbichler (Beitrag 1182854)

Das kommt auf die Implementierung an. Mit QPC kann ich wieder nanosekundenlang warten. Ok, blockierend, aber dafür extremstens(!) genauestens(!!1!EINS)

Ich lass mir doch mein Delay des 21.Jahrhunderts nicht durch Abarbeiten der MSQ ad absurdum führen.

Doch das tust du denn du hast im Normalfalle garkeinen Einfluß darauf. Nur wenn du einen Kernelmode Treiber programmieren könntest kämst du zumindest auf Betreibsystemebene nahe an das dran was du dir da erträumst. Aber dann hast du noch die Hardwareebene bestehend aus Non Maskablen Interrupts und den vielen anderen IRQs usw. die ebenfalls Prozessoraufmerksamkeit auf sich ziehen. Auch diese müsstest du unterbinden können, was theoretisch auch geht. Hast du das geschafft dann fehlt noch alles was CPU Latenzen/Waitstates erzeugen könnte wie Caches, DMA Transfers usw. Und das geht letzendlich nur durch direkte Eingriffe in die HW-Architektur. Mit anderen Worten: das Windows kein predictables OS ist liegt in der HW begründet. Du wirst es nicht schaffen mit einfachen CPU Zählern ein echtes und genaues Zeitmanagement in Nanosekunden Auflösung hinzubekommen. Sowohl nicht in der Reaktionszeit deines Codes auf diese Zähler noch bei der zeitexakten und unterbrechungsfreien Ausführung deines Codes.

Gruß Hagen

[Furtbichler]

Ich bin da nicht der richtige Ansprechpartner. Mir ist das alles schon klar.
Ich hätte wohl mehr :mrgreen: und :stupid: und :wink: in meinen Beitrag streuen sollen.