Schalte die blöde Überlaufprüfung des Compilers ab, DIE IST die Fehlerursache nicht der Code noch Windows. Das Problem ist recht schnell erklärt. Wenn der programmierer im Source sagt -> mache eine Subtraktion ohne Vorzeichen und benutze dazu den vorzeichenlosen Datentyp Cardinal/DWord dann baut der Compiler bei der Überlaufprüfung eine Prüfung MIT Vorzeichen ein. Statt also einen Wertebereich von 0 bis 2^32-1 wird auf Bereich -2^31 bis +2^31-1 geprüft.
Ich betone es immer wieder: die Überlaufprüfung der Delphi Compiler wurde von Version zu Version (also ausgehend vom guten alten BP4), von einem Präzisionsinstrument immer mehr zu einem Schätzeisen und schlußendlich zu einer nervigen Zecke. Das Problem wurde zusätzlich verschärft durch die manchesmal falschen Datentypen. So wurde der Typ Cardinal schonmal als Integer also vorzeichenbehaftet durch den Compiler implementiert und das galt nicht nur für diesen Datentyp. Daraufhin mussten die Entwickler tricksen, gewöhnten sich teilweise dran. Eine Version später hatte Borland solche Bugs teilweise entfernt und dafür den neuen Datentyp Int64 fehlerhaft eingebaut und schnarch langsam. Auch in den Windows-
API Schnittstellen gab es häufig solche Fehler, eben GetTickCount:Integer statt wie schon immer GetTickCount:Cardinal 32 Bit vorzeichenlos. Das ist nämlich immer schon ein 32Bit vorzeichenloser Rückgabewert, denn wer von Euch hat seinen Rechner schon -2^31 Millisekunden am Laufen bevor er diesen überhaupt eingeschaltet hat. Aber GetTickCount wurde eben lange Zeit mit Integer-Rückgabewert deklariert. Gleiches PerformanceCounter, am Anfang ein übles packed Record Konstrukt um einen Unsigned 64 Bit darzustellen, dann getrickst per Comp Fließkommatyp was ganz gut funktionmierte, dann ein Int64 also vorzeichenbehaftet obwohl man niemals den Rechner früher am Laufen haben kann bevor man ihn eingeschaltet hat und schlußendlich UInt64.
Nun das sind eben Entwicklungen in der Weiterentwicklung und Verbesserung eines Programmierwerkzeuges die ganz normal sind. Und wenn man nicht höllisch aufpasst dann verursachen solche Dinge schnell mal Überlauffehler usw. die eigentlich garkeine sind.
Bei Delay solltest du eben darauf achten das man nicht mit 2^31 Millisekunden Delays arbeitet, dafür habe ich diese Funktion garnicht erschaffen (naja davon abgesehen ist sie eh ein sehr gefährliches Instrument das ich ablehne weil es immer darauf hinausläuft das ein Programmierer der grundsätzlich an seinem Bedienkonzept was falsch macht auf Delay zurückgreifen muß, normalerweise braucht man niemals ein Delay() wenn man es richtig angeht).
Sollte es also bei Delay zu einem Überlauf kommen so ist das richtig und produziert laufzeittechnisch keinen Fehler, das habe ich schon berücksichtigt. Also selbst wenn GetTickCount in der ersten Abfrage einen Wert nahe 2^32 liefert so würde durch die Berechnung von Milliseconds := Tick - GetTickCount als inverse Operation dieser Überlauf wieder korregiert.
@Xong: dein Vorschlag verändert die geplante Funktionsweise des Originals. Milliseconds in WaitFor() ist ein releativer Wert und muß jedesmal neu errechnet werden da ansonsten die gesamte delay Funktion nicht nahezu exakt Milliseconds Millisekunden warten würde, sondern durchschnitlich betrachtet +Millisekunden länger.
Gruß Hagen