Gespräch simulieren??

[himitsu]

Zitat von Romiox:

Ist jetzt vielleicht mehr so ne Kleinigkeit, ...

Gut, hier sind die Ausgaben dadurch um 100 1000 Millisekunden verzögerst.

Abgesehn davon, daß weder Schleife noch ProcessMessages nötig sind.

[WladiD]

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.

[himitsu]

Zitat:

wirre Seitenefekte

Wo ich nur zustimmen Kann.
http://www.delphipraxis.net/167456-p...dows-test.html

[Iwo Asnet]

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

[Valle]

Zitat von Iwo Asnet:

[...] das Fragen direkt beantwortet werden sollten [...]

Die Eingangsfrage war klar: "Hier ist mein Code, der klappt nicht. Wieso?"
Antwort: "Nimm Application.ProcessMessages"

Die Eingesfrage war nicht warum. Eigentlich war gar keine Frage vorhanden. Interessanter finde ich eher diesen Teil des Ausgansposts:

Zitat von thechus:

Leider führt er alle Befehle gleichzeitig aus
Ich hab's auch schon mit einem Timer versucht.
Da kam das selbe bei raus.

Also wenn man es macht wie Iwo Asnet es meint, dann sollte geklärt werden, dass

• Windows hier definitiv nichts gleichzeitig ausführt
• warum sein gezeigter Code nicht klappt
• dass sein Timer-Versuch wohl fehlerhaft gewesen sein muss
• und was die richtige Lösung des Problems ist

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

[Furtbichler]

Zitat von Valle:

• Windows hier definitiv nichts gleichzeitig ausführt
• warum sein gezeigter Code nicht klappt
• dass sein Timer-Versuch wohl fehlerhaft gewesen sein muss
• und was die richtige Lösung des Problems ist

Die Panels werden erst beim nächsten Abarbeiten der anstehenden Messages neu gezeichent => Windows führt die Befehle scheinbar gleichzeitig aus.
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?

[Thom]

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;