Application->ProcessMessages() - Alternative
-
Hallo,
in meiner Anwendung nutze führe ich eine komplizierte Berechnung aus, wobei eine Funktion immer wieder aufgerufen wird. DIe Fuktion wird im schnitt 10x pro Sekunde aufgerufen.
Da Application->ProcessMessages() ziemlich vile zeit benötigt, habe ich alles dies gekickt. Meine Anwendung läuft nun schneller und alle Werte werden auch aktualisiert.
Problem ist nur, das ich die Anwendung nicht mehr verschieben kann. Was kann ich machen, damit ich meinen Code dennoch verschieben kann, ohne weitere Application->ProcessMessages() in meine Berechnungsfunktion einbauen zu müssen?
Martin
-
Applicatin->ProcessMessages() ist schon der richtige Weg, man muss halt nur steuern wie oft des aufgerufen wird.
Wenn es eine Schleife ist, kannst Du den Schleifenzähler verwenden, a la:
//Schleifenzähler soll x sein...
if (x % 100 == 0) Application... // wird jeden hundersten Durchlauf ausgeführtAnsonsten mußt Du eine globale Variable verwenden, die Du in der Funktion hochzählst und nach dem Ausführen von Appl->Pro... wieder zurücksetzt.
-
Joe_M. schrieb:
Applicatin->ProcessMessages() ist schon der richtige Weg, man muss halt nur steuern wie oft des aufgerufen wird.
Richtiger scheint mir hier der Weg über "Multithreading"... Seht euch mal die Klasse TThread an. TApplication::ProcessMessages() ist eigentlich eher ne Krücke welche man möglichst nicht benutzen sollte da sich dann ungewollt und unbewusst plötzlich Effekte herausbilden die man eigentlich nicht haben wollte und schon gar nicht erwartet hat. Ein StackOverflow ist da noch das einfachste Problem.
-junix
-
junix schrieb:
Richtiger scheint mir hier der Weg über "Multithreading"...
Das finde ich je nach Problemstellung einfach zu aufwendig.
junix schrieb:
TApplication::ProcessMessages() ist eigentlich eher ne Krücke welche man möglichst nicht benutzen sollte ...
Warum nicht? Setze ich in (fast) allen Programmen ein (seit BCB4) und hatte nie Probleme damit. Schließlich wird nur die Botschaftswarteschlange abgearbeitet. Wenn man da natürlich was verbockt...
junix schrieb:
...da sich dann ungewollt und unbewusst plötzlich Effekte herausbilden die man eigentlich nicht haben wollte und schon gar nicht erwartet hat. Ein StackOverflow ist da noch das einfachste Problem.
Kannst Du ein bißchen konkreter werden? Wie gesagt, ich hatte noch nie Probleme damit (Schwitz)...
-
Joe_M. schrieb:
junix schrieb:
Richtiger scheint mir hier der Weg über "Multithreading"...
Das finde ich je nach Problemstellung einfach zu aufwendig.
Was ist daran aufwendig, seine Routine in ein TThread-Objekt in die Execute-Routine zu knallen?
Joe_M. schrieb:
junix schrieb:
TApplication::ProcessMessages() ist eigentlich eher ne Krücke welche man möglichst nicht benutzen sollte ...
Warum nicht? Setze ich in (fast) allen Programmen ein (seit BCB4) und hatte nie Probleme damit. Schließlich wird nur die Botschaftswarteschlange abgearbeitet. Wenn man da natürlich was verbockt...
Das ist ja grad der Punkt.
Joe_M. schrieb:
junix schrieb:
...da sich dann ungewollt und unbewusst plötzlich Effekte herausbilden die man eigentlich nicht haben wollte und schon gar nicht erwartet hat. Ein StackOverflow ist da noch das einfachste Problem.
Kannst Du ein bißchen konkreter werden? Wie gesagt, ich hatte noch nie Probleme damit (Schwitz)...
Naja, geht man "vernünftig" damit um, gibts auch keine Probleme. Man muss sich einfach bewusst sein, das man eine Verschachtelung von TApplication::ProcessMessages verursachen kann, hat man mehrere verschiedene Routinen welche die Methode aufrufen.
Angenommen du hast Button 1 und 2, beide haben schleifen und verwenden "ProcessMessages". Drücke ich nun Button 1, wird das Ganze angeworfen. Drücke ich dann Button 2, wird der Druck beim Aufruf von ProcesssMessages() abgearbeitet. Da die Button2Click-Methode ja selber eine Schleife hat und ProcessMessages aufruft, wird Button1Click unterbrochen und wartet auf die Ausführung von Button2Click (natürlich unbewusst. Button1Click wartet eigentlich nur auf die Rückkehr von ProcessMessages()). Drücke ich wieder während Button2Click läuft Button1, wird ein neuer Schleifenstart losgetreten, Button2Click welche Button1Click unterbrochen hat, wartet nun auf Button1Click in der zweiten Ausführungsstufe, etc. pp. Man hat mit ProcessMessages eigentlich bereits ein Multitasking-Problem geschaffen. Nur sind die Tasks gegenseitig blockierend (Im Gegensatz zu Threads). Bin leider grad etwas knapp in der Zeit, daher nicht so ausführlich. Ich hoffe du weisst worauf ich hinaus will. Ansonsten ungeniert nachfragen.-junix