@roderich, absolut korrekter Einwand und Lösung.
Noch ein Tipp von mir: Es ist immer schwierig abzuschätzen wie oft man nun Application.ProcessMessages aufrufen sollte. Meistens macht man das zu wenig oder eben zu oft. Die beste Abschätzung die man treffen kannist das man alle 100 ms diesen Aufruf durchführen sollte. Man kann dies mit GetTickCount erreichen:
Delphi-Quellcode:
var
NextTick: Cardinal = 0;
procedure Poll;
var
Tick: Count;
begin
Tick := GetTickCount;
if Tick >= NextTick then
begin
Application.ProcessMessages;
NextTick := Tick + 100;
end;
end;
Die procedure Poll kannst du nun ohne Bedenken in die innerste Schleife einbauen. Sie ruft Application.ProcessMessages nun nur noch alle 100 Millisekunden auf. Der restliche Overhead mit dem Aufruf von GetTickCount dauert nur noch ca. 22 Taktzyklen.
Der richtige Weg wäre ein eigener Thread aber es gibt auch gute Gründe für ein Polling wie oben:
1.) wenn die Anwendung sowieso auf die aktuelle Berechnung warten soll
2.) Polling lässt die Anwendung smooth reagieren, Threads sind konkurrent zum Mainthread und sind entweder mit tpIdle zu langsam oder mit tpNormal zu schnelle eingestellt. Egal wie man es dreht, mit Threads erscheint die Anwendung in der Bedienung immer "ruckelig".
3.) mit Threads entsteht ein nicht zu unterschätzender Aufwand beim Threadübergreifenden Zugriff auf gemeinsamme Daten. D.h. sollte die Berechnung abgebrochen werden können, oder ein Fortschritt der Berechnung angezeigt weden sollen, so benötigt man mit Threads einen erhöhten Aufwand an Locking und Synchonisation. Meistens führt dieser Aufwand dazu das man mehr Reechenzeit verschwendet als nötig.
RTL CriticalSections und Messages mit SendMessage() verbrauchen viel mehr Rechenpower, als das simple Polling.
Also, wenn man nur EINE schnelle Berechnung machen möchte auf die der Anwender sowieso warten muß, dann lohnt sich die asynchrone Polling Methode. Wichtig dabei ist wie Radig es schon sagte das die Anwendung komplett gesperrt werden muß dabei.
Gruß Hagen