Ein Delay ist quasi verboten. Auch wenn es funktioniert macht es nur Probleme.
Bei allen Dingen wo man im Code warten muss, sollte man unbedingt einen Timer einsetzen.
Wenn etwas Asynchron, also direkt nach einer Taste ausgeführt werden soll, so kann man sich selbst eine Botschaft die die Message Queue schreiben, Beispiel:
Code: Alles auswählen
Application.QueueAsyncCall(@<Funktion die aufgeruden werdne soll>,<Pointer auf eine Datenstruktur>);
Somit kann man verschachtelte komplexe Aufrufe mit QueueAsyncCall voneinander korrekt trennen, die dann mit der Botschaftenschleife nacheinander aufgerufen werden.
Wenn man ein neues Windows hat, wie z.B. Win11 und man packt zu viele Delay's da rein, das mag Windows überhaupt nicht mehr dass so eine Funktion quasi aufgerufen wird und die sich nicht beendet. Neuerdings überwacht Windows die Dauer einer Funktion.
Daher >>> programmier es gleich "richtig".
Beispiel einer konkreten Anwenung von "QueueAsyncCall". Log Meldungen in das Log schreiben benötigen immer ziemlich Zeit, damit wird der aktuelle Prozess verlangsamt. Damit das ganze dennoch in der korrekten Reihenfolge im Log erscheint und nichts verloren geht kann man das über diese QueueAsyncCall lösen.
Code: Alles auswählen
type TLogMsgData = record // Record für Log in das Protokoll mit DoLog()
strLogTxt: string;
dtLog: TDateTime;
end;
PLogMsgData = ^TLogMsgData;
procedure TfrmMain.DoLog(strLogTxt: string);
var LogMsgToSend: PLogMsgData;
Begin
New(LogMsgToSend); // Speicher reservieren
LogMsgToSend^.strLogTxt:= strLogTxt;
LogMsgToSend^.dtLog := Now;
Application.QueueAsyncCall(@DoLogAsyncQueue, PtrInt(LogMsgToSend));
End;
procedure TfrmMain.DoLogAsyncQueue(Data: PtrInt);
var
ReceivedLogMsg: TLogMsgData;
begin
ReceivedLogMsg := PLogMsgData(Data)^;
try // Fehler im Log ignorieren
: : :
finally
Dispose(PLogMsgData(Data)); // Speicher wieder frei geben
end;
end;
Verein
Links
Suche