Gespräch simulieren??

[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;

[MrSpock]

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?

[himitsu]

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)

[DeddyH]

Update veranlasst den Parent, UpdateWindow auszuführen. Dazu sagt das MSDN:

Zitat:

The function sends a WM_PAINT message directly to the window procedure of the specified window, bypassing the application queue.

Das bedeutet im Umkehrschluss, dass lediglich das Control neu gezeichnet, aber keine anderen Nachrichten abgearbeitet werden. Die angesprochenen Seiteneffekte treten somit nicht auf, man kann also z.B. auch das Fenster nicht verschieben etc.

[Progman]

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:

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;

So kann man beliebige Aktionen in einer festlegbaren Reihenfolge ausführen.