Dann mach einfach die Quotes weg

Ja, reine Zitatposts sind halt nicht erlaubt,
bzw. Zitate werden nicht mit gezählt.

"Softwaredesigntechnisch" ist man mit der Idee eine Prozedur einem Thread mitzugeben völlig auf dem Holzweg!
Warum?
Ganz einfach, weil die Prozedur ja nicht im luftleeren Raum steht, sondern sie braucht auch Daten, mit denen sie arbeiten kann.
Diese Daten können natürlich in globalen Variablen zu finden sein, aber ich glaube über die negativen Auswirkungen von globalen Variablen wurde schon genügend diskutiert.
Eine Prozedur + dazu gehörende Daten ist aber nichts anderes als ein Objekt.

Anonyme Methoden oder Closures sind im Prinzip auch Objekte - sie bestehen aus der Methode ohne Namen sowie den "eingefrorenen" Daten zum Zeitpunkt ihrer Zuweisung.

Man kann es drehen und wenden wie man will; das was ein Thread tun soll (die "Arbeit" oder der Job) ist irgendwie immer eine Art von Objekt.
Wenn man sauber programmieren möchte, dann lässt man am Besten Objekte auch wie Objekte aussehen und leitet ganz normal von TThread ab:

markieren

Delphi-Quellcode:

TMeinThread = class(TThread)
public
  procedure Execute;override;
  // Eingabewerte
  property Report: .....
  .....
  // Ausgabewerte
  property xyz: TXyz ....
end;

Im Prinzip ist es ganz einfach:
man muss überlegen, was der Thread zum Arbeiten als Input braucht.
Der Zugriff auf globale Variablen oder Singletons ist tabu; wir übergeben die Daten über ein Property.
(selbst dann wenn die Daten letztendlich in einer globalen Variablen stecken)
Nachdem der Thread gelaufen ist muss man die Ergebnisse abgreifen.
Häufig ist es so, dass die Eingabevariablen gleichzeitig auch Speicher für die Ergebnisse sind.
Dann werden keine Properties für die Ausgabewerte benötigt und wir sind fertig.

Anonyme Methoden sind eigentlich Interfaces mit einer öffentlich Methode.
"Übegebene" Variablen werden als Kopie in diesem Interface angelegt.
Bei übergebenen lokalen Variablen wird, sobald sie innerhalb des aktuellen Prozeduraufrufs verändert werden, jeweils die Kopie aktualisiert.
Diese Aktualisierung gilt nur für den aktuellen Aufruf, wird die lokale Variable freigegeben, wird auch ihre Verbindung getennt und wird auch im nächten Prozeduraufruf nicht wiederverbunden.
Globale Variablen sollte man nicht übergeben oder nur threadsicher aufrufen, wozu auch externe Felder in Objekten zählen.

*angestaubten Thread hochhol*
Hallo,

da mein Anliegen dem Thread sehr ähnlich ist möchte ich keinen Neuen öffnen.
Vorweg: Ich habe bis jetzt noch nicht mit Threads gearbeitet. Ich habe nun schon eine ganze Weile mehrere Foren und Tutorials durchgeguckt aber so richtig klar ist mir das ganze noch nicht. Ich bin mir auch nicht 100%ig sicher, ob ein Thread für mich die richtige Lösung ist, da mein Programmablauf trotzdem sequentiell bleiben soll.

Ausgangssituration:
Ich habe eine Procedure in Unit A, welche einen Funktion in Unit B aufruft. Dieser Funktion werden Werte übergeben aufgrund dessen ein Gerät angesteuert wird, welches Messwerte liefert. Diese Messwerte werden dann wieder in den Werten gespeichert. Der Ablauf der Funktion dauert je nach Einstellungen 5-30 Sekunden. In dieser Zeit ist das Hauptprogramm nicht bedienbar. Das ist das Problem. So soll es z.B. auch möglich sein die Messung vorzeitig zu beenden. Ich habe mal versucht den Aufbau auf das nötigste zu beschränken.

zusammenfalten · markieren

Delphi-Quellcode:

unit Main

interface

uses
  Data;
{...}
procedure TMain.Messung;
var
  FData: TData;
  i: integer;
  Messzeit: integer;
  Messwert: double;
begin
  FData := TData.Create;

  for i := 0 to 5 do
  begin
    {Einlesen von Messparametern}
    Messzeit := 5;
    Messwert := 0;
    FData.Messen(Messzeit, Messwert);
    {Weiterarbeiten mit wirklicher Messzeit und Messwert}
  end;

  FreeAndNil(FData);
end;

markieren

Delphi-Quellcode:

unit Data
{...}

type
  TData = class
  public
    function Messen(var Messzeit: integer; var Messwert: double): boolean;
  end;

Es handelt sich also um eine Funktion mit var-Parametern. Die Schleife in der Main-Unit soll auch erst weiterlaufen, wenn die funktion "Messen" abgeschlossen ist.
Das ganze muss ich für viele verschiedene Funktionen mit unterschiedlichen Parametern machen. Gibt es da eine Allround-Lösung?

Wenn ich die Funktion als Procedure schreibe und das Beispiel von himitsu in Beitrag #9 verwende erhalte ich folgenden Fehler beim Aufruf von TMyThread.CreateThread(Procedure):
Inkompatible Type: 'TThreadProcedure' und 'procedure, untyped pointer or untyped parameter'

Ich habe auch versucht der Klasse TMyThread die Parameter über Properties vorher zu übergeben, dann den Thread zu starten und später wieder auszulesen. Leider wird der Execute-Abschnitt nicht sofort ausgeführt und meine Schleife läuft bereits weiter, bevor die Werte berechnet wurden.

Die Beispiele im Internet sind leider auch alle sehr allgemein gehalten und viele Dokumente, auf die in Foren verwiesen wurde, existieren nicht mehr.

Ich hoffe Ihr könnt mir einen Denkanstoß geben

Grüße
Headbucket

Wenn die VCL hängt und das nicht passieren soll, dann gibt es nur zwei Möglichkeiten:
- die Operation in einen Thread auslagern, damit der Hauptthread nicht blockiert wird
- immer mal wieder der VCL Zeit geben etwas zu tun (Application.ProcessMessages)

Wenn die Arbeit im aufrufenden Thread sequentiell bleiben soll, dann gibt es auch da mehrere Möglichkeiten:
- die aufrufende Prozedur im Hauptthread wartet, bis der Thread fertig ist. (muß beim Warten aber der VCL Zeit zum Arbeiten geben)
- der Thread sagt dem Hauptthread, daß sie fertig ist und in diesem Event wird dann die restliche/nachfolgene Arbeit verrichtet

Zitat:

Inkompatible Type: 'TThreadProcedure' und 'procedure, untyped pointer or untyped parameter'

Das ist auch richtig so, denn dort kann man nur Prozeduren, Methoden oder anonymen Methoden ohne Parameter verwenden!

Bei einer anonymen Methode kann man z.B. lokale Variablen indirekt übergeben => nicht via Parameter, sondern eher so, wie man auch eine Variable innerhalb eines Blocks (z.B. in einem IF oder einer FOR-Schleife) verwendet.
Oder man nutzt "globale" Variablen zum Zwischenspeichern, oder man erstellt eine eigene TThread-Klasse, wo die Werte via Felder der Klasse übergeben werden. In die Felder kommt es dann z.B. mittels Parameter im Constuctor oder als Property (bei verzögertem Start).

Vielen Dank schonmal für die Antwort. Ich habe mich eben nochmal rangesetzt und bin ein Stück weiter, denke ich.

Zitat von himitsu:

Wenn die VCL hängt und das nicht passieren soll, dann gibt es nur zwei Möglichkeiten:
- die Operation in einen Thread auslagern, damit der Hauptthread nicht blockiert wird
- immer mal wieder der VCL Zeit geben etwas zu tun (Application.ProcessMessages)

der VCL Zeit geben ist theoretisch möglich. Leider treten dann bei mir andere Probleme auf:
Ich starte eine Messung und muss diese z.B: nach 5 Sekunden wieder beenden. Die 5 Sekunden überbrücke ich mit einem Sleep. Wenn ich das Sleep durch eine Schleife realisiere und immer "Application.ProcessMessages" ausgebe, werden aus den 5 Sekunden mal ganz schnell 12. Vllt werde ich das nochmal mit einem Timer versuchen.

Das ganze in einem Thread auslagern gefällt mir aber ehrlich gesagt noch besser.
Ich habe die Übergabe der Parameter jetzt erstmal mit einem globalen Record gelöst, da es ein kleine Programm mit wenig Daten ist. Kein Problem also.

Ich habe nun ein ganz neues Problem. Ich starte z.B. zwei Threads:

markieren

Delphi-Quellcode:

hMyThread[0] := CreateThread(nil, 0, TFNThreadStartRoutine(@GetSPL), nil, 0, iThreadID);
  hMyThread[1] := CreateThread(nil, 0, TFNThreadStartRoutine(@GetVoltage), nil, 0, iThreadID);
  WaitForMultipleObjects(2, @hMyThread, true, Infinite);

Die erste Funktion (GetSPL) ruft eine Klassen-Funktion einer anderen Unit auf. Diese Funktion soll eine EXE-Datei starten und warten, bis diese beendet ist. Die Funktion sieht dabei so aus (habe ich auch aus dem Forum glaube ich):

zusammenfalten · markieren

Delphi-Quellcode:

function TMeasurement.StartAndWait(const ExecuteFile,ParamString: string): boolean;
var
  SEInfo : TShellExecuteInfo;
  ExitCode : DWORD;
begin
  Result := False;
  if not FileExists(ExecuteFile) then Exit;
  FillChar(SEInfo, SizeOf(SEInfo), 0);
  SEInfo.cbSize := SizeOf(TShellExecuteInfo);
  with SEInfo do
    begin
      fMask := SEE_MASK_NOCLOSEPROCESS;
      Wnd := Application.Handle;
      lpFile := PChar(ExecuteFile);
      lpParameters := PChar(ParamString);
      nShow := SW_SHOWMINIMIZED;
    end;
  if ShellExecuteEx(@SEInfo) then //hier bleibt er nun stehen und es geht nicht weiter
    begin
      repeat
        Application.ProcessMessages;
        Sleep(100);
        GetExitCodeProcess(SEInfo.hProcess, ExitCode);
      until (ExitCode <> STILL_ACTIVE) or Application.Terminated;
      Result := True;
    end;
end;

Leider bleibt er dann beim eigentlichen Aufruf der EXE-Datei stehen. Es muss ja irgendwie mit dem "WaitForMultipleObjects" zusammenhängen. Aber wieso? Muss ich diese Funktion nochmal in einen dritten Thread packen?

Grüße
Headbucket

Edit: Ich habe es jetzt mit einer abgeleiteten Klasse von TThread gelöst. Wenn ich den Funktionsaufruf dort in Execute habe, läuft alles Problemlos durch.