Also wenn du den Zustand von außen Pollen willst, dann macht es wenig Sinn, FreeOnTerminate auf true zu setzen, da das Objekt dann ggf. zu früh freigegeben wird. Aber den Zustand pollen macht sowieso keinen Sinn, entweder du benutzt das Ereignis OnTerminate oder du übergibst eine call-back-prozedur und rufst diese dann am Ende des Threads mit synchronize auf und machst dann dort mit Recordcount was immer du machen willst.

Oha, das mit dem OnTerminate ist ein guter Tipp. Hab das völlig übersehen. Statt mit dem Timer zu pollen, melde ich den RecordCount nun im OnTerminate. Danke!

Edit: Am Ende hat sich rausgestellt, dass im Thread eigentlich nur CoInitialize(nil) und CoUninitialize() gefehlt haben.

Hallöle...

markieren

Delphi-Quellcode:

constructor TQThread.Create(DataSource: TDataSource);
begin
  FDataSource := DataSource;
  FQuery := TADOQuery(FDataSource.DataSet);
  FreeOnTerminate := True; // <--

  inherited Create(True);
end;

Persönlich würde immer das inherited immer im Konstruktor an erste Stelle setzen. In deinem Falle greiftst auf eine Variable des TThread zu, die noch nicht existent sein sollte, weil das Create des TThread noch nicht durchlaufen ist. Warum das bei dir funktioniert, weis ich nicht... Klärt mich auf.

besser:

markieren

Delphi-Quellcode:

constructor TQThread.Create(DataSource: TDataSource);
begin
  inherited Create(True);

  FDataSource := DataSource;
  FQuery := TADOQuery(FDataSource.DataSet);
  FreeOnTerminate := True;
end;

Warum es funktioniert kann ich nicht sagen. Meine Vermutung: FreeOnTerminate ist eine Variable aus TThread und deswegen schon erreichbar.

Hier meine aktuelle, lauffähige Version des Threads, falls jemand etwas ähnliches braucht:

zusammenfalten · markieren

Delphi-Quellcode:

interface

type
  TQThread = class(TThread)
  private
    FQuery: TADOQuery;
    FDataSource: TDataSource;
    FRightsPk: Integer;
    FRecordCount: Integer;
    FIsRunning: Boolean;
    FQueryName: string;
  protected
    procedure Execute; override;

  public
    constructor Create(DataSource: TDataSource);
    destructor Destroy; override;

    property RightsPk: Integer read FRightsPk write FRightsPk;
    property RecordCount: Integer read FRecordCount write FRecordCount;
    property IsRunning: Boolean read FIsRunning write FIsRunning;
    property QueryName: string read FQueryName write FQueryName;
  end;

implementation

constructor TQThread.Create(DataSource: TDataSource);
begin
  inherited Create(True);

  FDataSource := DataSource;
  FreeOnTerminate := True;
end;

destructor TQThread.Destroy;
begin
  inherited;
end;

procedure TQThread.Execute;
begin
  inherited;

  CoInitialize(nil);

  try
    try
      FQuery := TADOQuery(FDataSource.DataSet);

      RightsPk := FDataSource.Tag;
      IsRunning := True;
      RecordCount := 0;
      QueryName := FQuery.Name;

      FQuery.Close;
      FQuery.Open;

      RecordCount := FQuery.RecordCount;
      IsRunning := False;
    except
      on Ex: Exception do
      begin
        dxMessageDlg('Fehler beim Ausführen des Query-Thead! (' + FQuery.Name + ', ' + Self.QualifiedClassName + ')' + #13#10#13#10 + 'Fehlermeldung: ' + Ex.Message + #13#10 + Ex.StackTrace + #13#10 + 'SQL: ' + FQuery.SQL.Text, mtError, [mbOK], 0);
      end;
    end;
  finally

    CoUninitialize();
  end;
end;

Um die Ergebnisse abzufragen, nutze ich das Event OnTerminate:

markieren

Delphi-Quellcode:

procedure TForm1.TerminateThread(Sender: TObject);
var
  RightsPk: Integer;
  RecordCount: Integer;
begin
  RightsPk := TQThread(Sender).RightsPk;
  RecordCount := TQThread(Sender).RecordCount;

  // Verarbeitung der Variablen
end

Ich sehe gerade, IsRunning ist hier sogar völlig überflüssig...

PS: Kann ich den ersten Beitrag nicht bearbeiten, um den Thread als "gelöst" zu markieren?

Hmm...

Zitat:

markieren

Code:

CoInitialize(nil);
  try
    try
      FQuery := TADOQuery(FDataSource.DataSet);

      RightsPk := FDataSource.Tag;
      IsRunning := True;
      RecordCount := 0;
      QueryName := FQuery.Name;

      FQuery.Close;
      FQuery.Open;

      RecordCount := FQuery.RecordCount;

Dir ist bewusst, dass der ADOQuery 'außerhalb' des Thread erzeugt wird und du somit innerhalb Execute auf die Komponente 'außerhalb' deines Threads zugreifst und das alle (eventuellen) Messages der ADOQuery im Hauptthread stattfinden?
Ich vermute, dass du eine ADOConnection mit diesem Query verwendest, welche auch außerhalb des Threads genutzt wird?
Also diese außerhalb deines Threads ist!

So weit ich weiß sollte jeder Thread seine eigende ADOQuery/ADOConnection selber erstellen, nur so ist sichergestellt, dass diese auch im Kontext des Threads läuft!

Also den Connectionstring, sowie den SQL-String an den Thread geben und nicht das ADOQuery selber!.

Irgendwo habe ich nen Sourcecode gesehen, welcher dann das Record-Set Thread Save aus dem Thread an den MainThread zurück gibt, weiß aber nicht mehr wo....