AW: Gespräch simulieren??
Ihr solltet aufhören den Einsatz von Application.Processmessages zu empfehlen!
In einem Test-Projekt ist der Einsatz noch ok, aber wenn sich zu viele Application.Processmessages in einem Produktivsystem ansammeln, so hat das allerlei Seiteneffekte, die nicht nachvollziehbar und sehr schwierig zu debuggen sind. Stellt euch doch einfach mal vor, was der Aufruf von Application.Processmessages alles ausführen kann: Timer werden abgearbeitet, Thread-Synchronisierung (TThread.Synchronize) wird durchgeführt, kurz gesagt alle Messages, und das in irgendeinem Event-Handler?! Da hat Borland seinerzeit definitiv einen Designfehler gemacht, TApplication.Processmessages hätte protected sein müssen. Ich arbeite an einer historisch gewachsenen Anwendung, die noch vor einem Jahr über 150 Aufrufe dieser Methode hatte, nunja, die Anwendung war in vielen Fällen einfach unberechenbar. Mit jedem Release versuche ich es Stück für Stück zu entfernen und es läuft immer besser. |
AW: Gespräch simulieren??
Zitat:
http://www.delphipraxis.net/167456-p...dows-test.html |
AW: Gespräch simulieren??
Ich glaube immer noch fest daran, das Fragen direkt beantwortet werden sollten und Tipps, wie man es besser machen kann, als unverbindliche Empfehlung zusätzlich dargeboten werden sollten.
Die Eingangsfrage war klar: "Hier ist mein Code, der klappt nicht. Wieso?" Antwort: "Nimm Application.ProcessMessages" Trotzdem sind die weitergehenden Diskussionen und Anmerkungen, insbesondere die über den schlechten Stil in Bezug auf die ProcessMessages, durchaus sehenswert und sehr interessant. Persönlich halte ich nicht viel davon, Methoden, mit denen man Schindluder treiben kann, in die 'protected' Ecke zu verbannen. Das müsste man dann auch mit einem Gaspedal beim Auto machen :stupid: |
AW: Gespräch simulieren??
Zitat:
Zitat:
Und wenn man will, kann man auch den Hack Application.ProcessMessages erwähnen. Natürlich ist es eine Sache des Antwortenden, ob er Lust und Zeit hat, dem TE breit zu erklären warum das alles so ist. Immerhin ist das System für einen nicht-eingeweihten nicht so einfach zu verstehen. Aber besonders der Timer gehört zu den Grundlagen, die man als bessere Alternative zur genannten Methode durchaus darlegen darf. ;-) Liebe Grüße, Valentin |
AW: Gespräch simulieren??
Zitat:
Durch den Aufruf von ProcessMessages klappt der gezeigte Code (Hilfe vollständig gegeben), der Timer-Versuch ist nicht dokumentiert und die 'richtige' Lösung ist abhängig vom Problem und der Fragestellung. Hmmm. Was wolltest Du nochmal? ;-) Ich habe die Frage auch so verstanden, das er wissen wollte, wieso sein Code nicht klappt. Dessenungeachtet ist das hier mal wieder Wortklauberei. Ehrlich gesagt halte ich es für durchaus legitim, in einem Button-Event, der etwas länger dauert, ein Application.ProcessMessages aufzurufen. Wenn ich z.B. einen Batch starte, der z.B. 10000 Datensätze importiert, zeige ich Fortschritt, verstrichene Zeit, usw. innerhalb der Schleife an und rufe dann Application.ProcessMessages auf. Wieso sollte man das anders machen? Es ist straight forward und reicht vollkommen aus. Ich vermute, die weitaus meisten Fortschrittsanzeigen sind ähnlich aufgebaut. Insofern verstehe ich nicht, wieso der Aufruf von ProcessMessages ein Hack sein soll. Klar, man kann den ganzen Schmoo in einen Thread auslagern. Klar, man kann die Anzeige über einen Timer lösen. Klar, man kann endlos darüber diskutieren. Aber warum? |
AW: Gespräch simulieren??
Es geht nicht darum, ewig zu diskutieren, sondern nur um die hier im Forum übliche "Meine Sicht ist die einzig wahre..."-Streiterei.
WladiD hat vollkommen Recht: Der Aufruf von Application.ProcessMessages kann zu schwer lokalisierbaren Zugriffsverletzungen führen. Dazu gab es erst vor kurzem eine Diskussion. Manche Probleme lassen sich allerdings nur unzureichend ohne den Einsatz von Application.ProcessMessages lösen, da damit nicht nur Nachrichten abgearbeitet, sondern zum Teil auch Rechenzeit abgegeben wird, was für manche Aufgaben äußerst wichtig ist. Allerdings sollten dann auch entsprechende Sicherheitsmaßnahmen getroffen werden. Wenn es nur darum geht, ein Steuerelement zu aktualisieren, reicht der Aufruf der Methode Update vollkommen aus, ist ebenfalls in einer Zeile erledigt und birgt nicht die mit Application.ProcessMessages verbundenen Risiken:
Delphi-Quellcode:
procedure TForm1.Button1Click(Sender: TObject);
var n: Integer; begin for n:=0 to 10 do begin Label1.Caption:=IntToStr(n); Label1.Update; Sleep(200); end; end; |
AW: Gespräch simulieren??
Ist das tatsächlic so, dass der Aufruf von Update ausreicht? Ich hätte vermutet, dass Update nur eine Nachricht an das entsprechende Element schickt, die aber ggf. nur abgearbeitet wird, wenn Windows "Zeit" dafür hat und explizit mit Application.ProcessMessages dazu aufgefordert wird. In deinem Beispiel funktioniert das wohl, aber grundsätzlich ist das kein Ersatz, oder? :?
|
AW: Gespräch simulieren??
Update ruft standardmäßig direkt/sofort UpdateWindow auf.
Bei Update, Refresh und Repaint kommt aber letzendlich darauf an, wie bei dem Control diese Methoden implementiert sind. (also ob und wie sie überschrieben/verändert wurden) |
AW: Gespräch simulieren??
Update veranlasst den Parent, UpdateWindow auszuführen. Dazu sagt das MSDN:
Zitat:
|
AW: Gespräch simulieren??
Betreffs des Eingangsproblems:
Man könnte das durchaus mit einem Timer sehr elegant lösen. Man nimmt sich eine (integer) Zählvariable, die auf Null gesetzt wird. Diese wird im Timer-Ereignis jedesmal erhöht. Je nach ihrem Wert kann in einer Case-Anweisung bestimmt werden, was passieren soll. Ich nenne sie hier mal Phase.
Delphi-Quellcode:
So kann man beliebige Aktionen in einer festlegbaren Reihenfolge ausführen.
procedure TfrmMain.Timer1Timer(Sender: TObject);
begin Timer1.Enabled:=False; case Phase of 1: begin //erstes Panel beschriften, sichtbar, Refresh Timer1.Interval:=1500; //1,5 sek end; 2: begin //zweites Panel beschriften, sichtbar, Refresh Timer1.Interval:=1000; //1 sek end; 3: begin //drittes Panel beschriften, sichtbar, Refresh Timer1.Interval:=2000; //2 sek end; //beliebig erweiterbar.... end; inc(Phase); if Phase < 4 then //maximalwert der Phase + 1, ansonsten wird der Timer nicht mehr enabled Timer1.Enabled:=True; //nächsten Intervall durchlaufen end; |
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:48 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz