Sekunden in Millisekunden für Sleep umwandeln

[himitsu]

Nur mal zur Info: Es gibt ein paar Konstanten zur Zeitkonvertierung.

Zitat:

Delphi-Quellcode:

  HoursPerDay   = 24;
  MinsPerHour   = 60;
  SecsPerMin    = 60;
  MSecsPerSec   = 1000;
  MinsPerDay    = HoursPerDay * MinsPerHour;
  SecsPerDay    = MinsPerDay * SecsPerMin;
  SecsPerHour   = SecsPerMin * MinsPerHour;
  MSecsPerDay   = SecsPerDay * MSecsPerSec;

SysUtils


Laut Definition will SetWaitableTimer direkt den LARGE_INTEGER und keinen "QuadPart".

[a.def]

Ich mache das jetzt so

Delphi-Quellcode:

procedure TForm1.LongDelay(Milliseconds: Cardinal);
var
 FirstTickCount: DWord;
begin
 FirstTickCount := GetTickCount;

 while ((GetTickCount - FirstTickCount) < Milliseconds) do
  begin
   if not ThreadRunning then // nur ein Beispiel! (das hier steht hier nur, damit bei Programmende nicht unnötig hier gewartet wird)
    Exit;

   Application.ProcessMessages;
   Sleep(0);
  end;
end;

// Eingabe Nutzer: 600
var
 dTmp: Single;
 iMaxImgLifetime: Integer;
begin
 dTmp := (StrToIntDef(sSecondsInput, 600) / 20); // 20 = Anzahl Bilder
 iMaxImgLifetime := Round(dTmp * 1000); // Lebenszeit eines Bildes, bevor es versteckt wird

 // Thread
 while ... do
  begin
   LongDelay(iMaxImgLifetime);

   // Arbeite ...
  end;

[himitsu]

Nur keine Ahnung, warum jemand sich so viele Umstände macht anstatt das ganze Problem mit 2 Zeilen Code und einem TTimer zu lösen.

[a.def]

Weil ein Timer hier die GUI minimal blockieren würde. Statt einen Timer läuft es bei mir in einem TTask, ist doch kein Problem?

[himitsu]

Nein, es läuft nicht alles im Thread und wenn doch, dann hast du da einen schweren Designfehler im Programm, denn auf die VCL greift man ausschließlich vom Haupthtread drauf zu.
Der Task/Thread macht doch scheinbar nichts anderes, als sinnlos zu warten und dann das Bild zu änder.

Das Einzige, was hier "eigentlich" gemacht wird, ist alle x Sekunden in der GUI ein Bild zu ändern.
Das Ändern dauert immer gleich lang, egal ob es direkt im VCL-Thread von einem Timer ausgeführt wird
oder ob man es aus einem Thread synchronisiert im VCL-Thread macht.

[a.def]

Habs jetzt in einen Timer gepackt. Kein TTask mehr, kein Synchronize mehr, kein LongDelay mehr
Das Interval ist die Zeit die vorher meine Sleep-Dauer war.
Im Timer ist bei jedem Durchgang ein ProcessMessages.

[stahli]

Das ist gut so, wie auch himitsu empfohlen hat.

Aber das ProcessMessages ist sicherlich überflüssig.
Erstens wird es keinen positiven Effekt haben und zweitens kann es durchaus Probleme machen.

Was willst Du damit erreichen?

[t.roller]

Zitat von himitsu:

Laut Definition will SetWaitableTimer direkt den LARGE_INTEGER und keinen "QuadPart".

Zeit.QuadPart ist INT64.
Largeint ist ein 8 Byte großer Integerwert mit Vorzeichen.
Ist also das Gleiche!

WINDOWS.PAS:
LARGE_INTEGER = record
case Integer of
0: (
LowPart: DWORD;
HighPart: Longint);
1: (
QuadPart: LONGLONG);
end;
TLargeInteger = Int64;

Zitat:
Remarks

The LARGE_INTEGER structure is actually a union. If your compiler has built-in support for 64-bit integers, use the QuadPart member to store the 64-bit integer. Otherwise, use the LowPart and HighPart members to store the 64-bit integer.

[stahli]

@a.def

Die Positionsberechnung führst Du sicher in einem anderen Ereignis durch - oder?
Dann ruf Deine Positionsberechnung einfach noch mit in der Timer-Behandlung auf. Dann sollte das eigentlich funktionieren.

Mit Application.Processmessages schiebst Du im Grunde auch nur eine zusätzliche Ereignisbehandlung in die Timerbehandlung hinein.
Das kann aber Probleme machen - siehe hier: http://www.delphipraxis.net/190294-p...alsection.html

Kannst Du sonst mal ein Demoprojekt anhängen? Das sollte eigentlich ohne ProcessMessages funktionieren.

[himitsu]

Das Timer-Event ist eine Message und direkt danach werden alle weiteren Messages verarbeitet, es bringt also eigentlich garnichts, wenn man das vorher selber die Messages verarbeiten will, abgesehn von den genannten Problemen mit den rekursiven Aufrufen.