Hab das jetzt so gelöst jetzt funktioniert es allerdings lässt sich das fenster nicht mehr verschieben wenn der Thread am zählen ist.

zusammenfalten · markieren

Delphi-Quellcode:

type
  ParseThread = class(TThread)
  private
    { Private-Deklarationen }
     Form1: TForm1;
     i:integer;
    protected
    procedure Execute; override;
    procedure DoSomething;
   public
    { Public-Deklarationen }
     constructor Create(Form1: TForm1);
end;

var
  Form1: TForm1;
  tt: ParseThread;

implementation

{$R *.dfm}

procedure ParseThread.Execute;
begin
 while not Terminated do
   begin
     Synchronize(DoSomething);
   end;
end;

procedure ParseThread.DoSomething;
begin
     inc(i);

    form1.Memo1.Lines.Add(inttostr(i));

 if i = 5000 then begin
    i:=0;
    SuspendThread(tt.Handle);
 end;
end;

constructor ParseThread.Create(Form1: TForm1);
begin
  inherited Create(False);
  Self.Form1 := Form1;
end;

procedure TForm1.BitBtn1Click(Sender: TObject);
begin
 tt := ParseThread.Create(Self);
 tt.FreeOnTerminate := true;
end;

end.

      Synchronize(DoSomething); Damit eliminierst du den Vorteil eines Threads und kannst ihn auch gleich weg lassen.

Hör auf den Rat den du hier im Forum bekommen hast, und arbeite ich in die Grundlagen ein.

Zitat von DieDolly:

      Synchronize(DoSomething); Damit eliminierst du den Vorteil eines Threads und kannst ihn auch gleich weg lassen.

Ich lese das immer wieder, aber es stimmt einfach nicht. Ja, Synchronize blockiert den Thread während der Aktualisierung. Es macht insofern keinen Sinn, 100% der Arbeit des Threads in einer Synchronize-Methode zu machen.

Aber es funktioniert, ist zuverlässig und einfach - und sofern der Thread 90% seiner Arbeit außerhalb des Synchronize macht, auch kein Problem!

Also ja, das ist sinnlos:

markieren

Delphi-Quellcode:

procedure ParseThread.Execute;
begin
 while not Terminated do
   begin
     Synchronize(DoSomething);
   end;
end;

Das hingegen absolut sinnvoll und schön kurz + gut lesbar:

markieren

Delphi-Quellcode:

procedure ParseThread.Execute;
begin
  while not Terminated do
  begin
    LongrunningCalculation();
    Synchronize(ShowProgress);
  end;
end;

Wobei LongrunningCalculation ruhig länger dauern darf (ist ja entkoppelt vom Hauptthread) und die Ergebnisse in Feldvariablen der Klasse schreibt. Da Synchronize blockiert, sollte Zugriff auf die Feldvariablen sicher sein. (Das ist mMn auch der Grund, weshalb es blockiert: Damit man über private Felder Daten austauschen kann)

Da inc(i) eben sehr flott ist, ist mMn das Beispiel schlecht gewählt. Eventuell ginge Primzahlen finden besser, da zeitaufwändiger ...?

Es hat mich nicht ganz losgelassen, daher hier mal ein Beispiel das Primzahlen sucht. Ja, die Berechnung ist absichtlich langsam, wobei ich nicht schätzen kann, wie langsam (Und ich hab das ohne IDe hingetippt, vll. sind da noch kleine Fehler drin)

Der Thread ist (bzgl. Abhängigkeiten) entkoppelt von der UI und steltl nur ein Event zur Verfügung. die UI kann (am Besten in einer anderen unit) dann das Event abonnieren und den Fortschritt anzeigen.

zusammenfalten · markieren

Delphi-Quellcode:

type

TPrimeInfoEvent = procedure(Sender: TPrimeFinderThread; number: Integer) of Object;

TPrimeFinderThread = class(TThread)
  private
    testNumber: Integer;
    isPrime: Boolean;
  protected
    procedure Execute; override;
    procedure ShowProgress;
    function IsNumberPrime(number: Integer);
    fProgressCallback: TPrimeInfoEvent;
  public
    { Public-Deklarationen }
    constructor Create(Form1: TForm1);
end;

implementation

constructor PrimeFinderThread.Create(callback: TPrimeInfoEvent);
begin
  inherited Create(False);
  Self.fProgressCallback = callback;
  FreeOnTerminate := True;
end;

procedure PrimeFinderThread.Execute;
begin
  testNumber = 10000;
  while not Terminated and testNumber < 1e7 do
  begin
    if IsNumberPrime(testNumber) then
      Synchronize(ShowProgress);

    testNumber := testNumber+1;
  end;
end;

procedure PrimeFinderThread.ShowProgress;
begin
  fProgressCallback(Self, testNumber);
end;

function PrimeFinderThread.IsNumberPrime(number: Integer): Boolean;
var
  i: Integer;
  divisorCount: Integer;
  remainder: Integer;
begin
  divisorCount := 0;
  for i := 1 to number do
  begin
    remainder := number;
    while remainder >= i do { remainder := number mod i }
    begin
      remainder := remainder - i;
    end
    if remainder = 0 then
      inc(divisorCount);
  end
  Result := divisorCount = 2;
end;

end.

Vielen Dank an alle.

Das mit der Trennung von Anzeige und Daten ist so eine Sache, da die Anzeige ja die Daten anzeigt
Bedeutet, ich interagiere ja in dem Moment, wo ich die Daten lade, ja schon mit der Anzeige, da das VCL-Objekt ja die Daten lädt.

Ich nochmal.

Zitat:

Bedeutet, ich interagiere ja in dem Moment, wo ich die Daten lade, ja schon mit der Anzeige, da das VCL-Objekt ja die Daten lädt.

Nein. Du interagierst (solltest du), *nachdem* du die Daten geladen hast. Nicht während dessen. Der Thread hat die Daten zu lesen/bearbeiten/was auch immer und sollte diese sich in einer Struktur merken, die einfach weiter zu verwenden ist. Zum Beispiel könnte der Thread eine Eigenschaft LoadedData haben. Und wenn der Thread das befüllt, muss er nichts synchronisieren. Sobald der Thread seine Eigensschaft LoadedData befüllt hat (Verarbeitung der Daten beendet) ruft er einmal eine Methode der Form über Synchronize auf. Die Form weißt dann ihren Controls die relevanten Sachen aus LoadedData zu. Damit ist das Laden komplett im Thread, die Anzeige der geladenen Daten komplett in der GUI. So würde das vorgehen Sinn machen (meiner Meinung nach).

@wicht,

das klingt einleuchtend!
Werde das mal probieren umzusetzen.

Danke nochmal an alle!

Hallo,

darf ich auch mal eine Frage bezüglich Threads stellen?

Bis dato hatte ich noch keine Threads für meine Anwendungen benötigt, bei meinem jetzigen
Projekt (Lichtsteuerung) sollten/müssen mehrere dinge selbstständig laufen.

Mein Problem ist das ich zur Laufzeit mehrere Frames erzeuge je nach Anzahl der Scheinwerfer.
Nun versuche ich in den Frames einen Thread zu integrieren damit diese Frames selbstständig ihr
Werte für die visuelle Darstellung erzeugen. Die Daten dafür sollen sie sich aus dem Hauptform
aus einem record hohlen.

Geht das überhaupt da die threads ja mit den Frames zu Laufzeit erzeugt werden.

MfG Dirk

Funktionalität und Darstellung sollten in einem Programm sowieso getrennt sein.
Bei Threads ist das Pflicht.
Ein Beispiel wie man das in diesem Fall angehen könnte:

Definiere eine eigene Nachricht:
WM_STATUS = WM_USER + xxxx;

Aufgabe des Hauptthreads:
Vergieb für jede Aufgabe eine Nummer/ID.
Erzeuge entsprechende Threads und übergib diesen ihre Aufgaben und das Handle eines Fensters
(das über Statusänderungen informieren soll).
Erzeuge entsprechende Frames für jede zu visualisierende Aufgabe.

Aufgabe des Subthreads:
Führe deine Aufgabe aus.
Ändert sich der Status, informiere das angegebene Fenster:
PostMessage(WindowHandle, WM_STATUS, ID, 0);

Aufgabe des Hauptthreads:
Wenn eine Nachricht von über eine Statusänderung eintrifft,
finde auf Grund der ID das entsprechende Frame und rufe die Methode zur Aktualisierung der Darstellung auf.

Statt Nachrichten könnte man auch Synchronize verwenden, das bremst aber die Subthreads aus.

Hallo

Danke werde mich mal mit der sache beschäftigen, habe ich noch nicht gemacht.

MfG