Prog friert scheinbar mit "Keine Rückmeldung" ein

[ManniSt]

Mein Prog zur Zahlenverarbeitung friert scheinbar mit der Meldung "Keine Rückmeldung" ein.
Die Progressbar bleibt stehen. Der Taskmanager zeigt noch immer eine stabile und aktive Prozessorlast an. Ich weis aber dann nicht mehr, wieweit das Teil schon ist.

Das Ganze läuft super durch, solange das Fenster, z.B. zum Verschieben, nicht angepackt wird. In diesem Fall friert die Anzeige sofort ein.

Hat da jemand eine Lösungsidee???

for I := MVon to MBis do
begin
if IstErgebnis(I) = true then writeln(Datei,I);
if (GetTickCount - Tick4) > 250 then // Alle 250ms ProgressBar.Update
begin
Tick4 := GetTickCount;
ProgressBar.Position := I;
ProgressBar.Update;
end; // if (GetTickCount - Tick4) > 250 then
end; // for I := MVon to MBis do
ProgressBar.Position := Max;

[hoika]

Hallo,

Delphi-Quellcode:

ProgressBar.Update;

Application.ProcessMessages;

[jfheins]

Wenn die Berechnung länger dauert, solltest du das idealerweise in einen Thread auslagern.

Dann hat dein Programm 2 Threads: Einer für das Formular und relativ unabhängig davon einer der rechnet. Die Forschrittsmeldungen in die UI sind dann aber etwas komplexer.

Falls sich deine Berechnung parallelisieren lässt, kannst du sie auch auf 2-3 Threads aufteilen und so beschleunigen. (Threads können vom Betriebsystem auf mehrere Kerne der CPU verteilt werden)

[DeddyH]

Die Holzhammer-Methode: innerhalb der Schleife Application.ProcessMessages aufrufen. Die elegantere und solidere Lösung: die Schleife in einen Thread auslagern und bei Bedarf synchronisiert auf die Oberfläche zugreifen. Beispielcode sollte sich reichlich im Forum finden lassen.

[ManniSt]

Application.ProcessMessages;

ist die Lösung!

DANKE!!!

Muss mich mal mit Threads beschäftigen, habe ich beisher nicht getan.

Manni

[jfheins]

Zitat:

Zitat von DeddyH (Beitrag 1457090)

Die Holzhammer-Methode: innerhalb der Schleife Application.ProcessMessages aufrufen. Die elegantere und solidere Lösung: die Schleife in einen Thread auslagern und bei Bedarf synchronisiert auf die Oberfläche zugreifen. Beispielcode sollte sich reichlich im Forum finden lassen.

Ich bin mal so nett, weil ich Application.ProcessMessages wirklich nicht mag ;-)

So in der Richtung müsste das aussehen:

Delphi-Quellcode:

type
  TMyThread: class (TThread)
    Progress: Integer;

    procedure Execute; override;
    procedure VCL_Result;
  end;


procedure TMyThread.Execute;
var
   T: Integer;
begin
   Progress := 0;
   synchronize (VCL_Result);
   T = GetTickCount();

   // Der Threadcode
   for ....
      if Integer(GetTickCount() - T) > 250 then begin
         T := GetTickCount();
         synchronize (VCL_Result);
      end;
      
      // Rechnen
   end;

   Progress := 100;
   synchronize (VCL_Result);
end;

procedure VCL_Result
begin
   Form1.ProgressBar.Position := Progress;
end;

[ManniSt]

Danke dafür, muss ich mich mal demnächst damit beschäftigen. Habe noch 1-3 Projekte abzuschließen aber dann ...

Manni

[DieDolly]

Zitat:

Application.ProcessMessages;

ist die Lösung!

DANKE!!!

Ob das jetzt die Lösung ist, sei dahingestellt. Ich habe immer gelernt, man sollte ProcessMessages niemals nutzen.

[ManniSt]

Schon gut, bis auf weiteres ist das die Lösung.

[DieDolly]

Wenn du dein Programm so aufbaust, dass du immer nur die erst-beste "Lösung" nimmst, wirst du irgendwann deinen Code in die Tonne kloppen können und dich fragen, was du damals fdür einen Mist geschrieben hast.

[Luckie]

ProcessMessages sorgt dafür, dass das Programm die eigentliche Codeausführung unterbricht, in die Nachrichtenschleife des Programmes springt, dort alle mittlerweile aufgelaufenen Nachrichten abarbeitet und dann wieder zum eigentlichen Programm zurückkehrt.

Wenn du jetzt das Fenster ständig hin und her schiebst, bekommt das Fenster eine WM_PAINT Nachricht nach der anderen und das Programm kommt nicht mehr zum ausführen des eigentlichen Programmcodes. Lagerst man aber den rechenintensiven Code in einen separaten Thread aus, kann auch die Nachrichtenschleife die eigentliche Programmausführung nicht behindern. Zu dem bist du flexibler, was die Synchronisation, Priorität usw. mit dem Hauptthread betrifft. Deswegen ist einen Thread einem ProcessMessages immer vorzuziehen. Außerdem ist es eleganter. :wink:

Bezüglich Threads: http://michael-puff.de/Programmierung/Delphi/Tutorials/ -> Threads in Delphi. Da beschäftige ich mich zwar hauptsächlich mit Threads in der WinAPI, aber ein Kapitel ist auch Threads mit der VCL gewidmet.

[haentschman]

Moin...:P

Zitat:

Ich habe immer gelernt, man sollte ProcessMessages niemals nutzen.

...irgenwann ist es immer das erste Mal. Ich hatte mal einen Fall mit einem Label was sich ums verrecken nicht aktalisieren ließ. :? Refresh hat es nicht interresiert. Nur ein Application.ProcessMessages half. :?