Auf 'Parent Object' zugreifen

[Julian M.]

Hallo,

wahrscheinlich stell ich mich mal wieder zu dusslig an aber,
wie greife ich auf das 'Parent Object' zu?

Also der Hintergrund ist,
sagen wir ich habe ein Objekt der Klasse TFileExplorer. Dieses Objekt beinhaltet wiederum Objekte der Klassen TFileStringList und TFindFileThread.

Der FindFileThread, welcher die Dateiliste erstellt soll diese nun in die FileStringList schreiben.

Meine Lösung wäre nun, dem Thread beim Start das aufrufende Objekt mitzugeben, also so:

Delphi-Quellcode:

  findFileThread.callinginstance := self;
  findFileThread.Start;

Und im Thread dann so auf die Stringlist zuzugreifen:
TFileExplorer(callinginstance).FileStringList := FindAllFiles;
Ist es so korrekt wie ich es machen würde oder gibt es eine Lösung ohne dem Thread das aufrufende Objekt mitzugeben?

Cheers,
Julian

[Julian M.]

Also erstmal hatte ich vergessen zu erwähnen dass es sich beim Thread um einen Thread der Klasse TThread handelt und ich Lazarus/Freepascal verwende.

Des Weiteren habe ich mir die Frage wohl schon selbst beantworten können.
Und zwar ist es denke ich eleganter, Objekte in einem eigenen constructor zu übergeben. zweitens braucht mein Thread ja nicht dessen Parent, sondern die Stringlist des Parent. Drittens eignet sich dafür ein Pointer

Delphi-Quellcode:

type
  TFileWalker = class(TThread)
  protected
    procedure Execute; override;

    private
    Ffilepath: string;
    FStringListPointer :^Tstringlist;
    Freceiverformhandle:HWND;
  public
    constructor Create(StringListpointer:Pointer:Pointer; filepath:String; receiverformhandle: HWND);
end;   


constructor TFileExplorer.Create(StringListpointer:Pointer; filepath:String; receiverformhandle: HWND);
begin
  inherited create(true);
  FStringListPointer := StringListpointer;
  Ffilepath :=  filepath;
  Freceiverformhandle := receiverformhandle;
  self.Start;
end;

[ConnorMcLeod]

Ich sehe eine Schwierigkeit: was, wenn der Thread länger braucht, als die übergebene TStringList lebt? Die KÖNNTE währenddessen zerstört worden sein. Meine Lösung wäre, dem Thread eine Callbackprozedur zu übergeben, die nach Beendigung im Mainthread ausgeführt wird. Darin wird dann die TStringList befüllt.

[hoika]

Hallo,
fehlt da nicht auch noch der Hinweis auf Synchronize?
Es geht ja schon um den Oberflächen-Zugriff eines anderen Threads.

[ConnorMcLeod]

Hatte ich vorausgesetzt, aber Du hast Recht - sollte erwähnt werden

[Blup]

Ein Pointer auf eine Variable einer Instance von TStringList ist an sich schon wiedersinnig.
Es kann nicht sichergestellt werden, dass die Variable oder der Inhalt der Stringliste außerhalb verändert wird oder überhaupt noch gültig ist.
Mit einer Kopie der Stringliste zu arbeiten, erscheint mit sicherer.

Delphi-Quellcode:

type
  TFileWalker = class(TThread)
  protected
    procedure Execute; override;
  private
    FFilepath: string;
    FStringList:  TStringList;
    FFreceiverFormHandle: HWND;
  public
    constructor Create(AStrings: TStrings; AFilepath: string; AReceiverFormHandle: HWND);
    destructor Destroy; override;
  end;


constructor TFileExplorer.Create(AStrings: TStrings; AFilepath: string; AReceiverFormHandle: HWND);
begin
  inherited Create(False);

  FStringList := TStringList.Create;
  FStringList.Assign(AStrings);

  FFilepath := AFilepath;
  FFReceiverFormHandle := AReceiverFormHandle;
end; 

destructor TFileExplorer.Destroy;
begin
  FStringList.Free;

  inherited;
end;

"Start" ist nicht erforderlich, wenn man "CreateSuspended" auf False setzt.
Der Thread wird automatisch gestartet, wenn der Constructor beendet ist.

[Julian M.]

Ich danke euch sehr für das Feedback! Wirklich toll, wie hier Probleme aufgezeigt werden.

Die StringList lebt so lange, bis sie durch erneuten Aufruf des FileExplorer (versehentlich habe ich einmal den Namen "FileWalker" hier eingeschleust)
neu created wird.

Die Gefahren des Multithreadings sind mir bewusst, da Freepascal leider keine anonymen Methoden unterstützt, ist mir die Nutzung von Synchronize eigentlich etwas zu aufwendig.
Als (zugegeben dürftige) Alternative nutze ich die Windows Messages.

Daher beim Erstellen des FileExplorer Threads auch die Übergabe der receiverformhandle: HWND
Der Thread ruft dann nach Befüllen der StringList den Befehl auf: SendMessage(Freceiverformhandle, 1125, 1, 0);

Delphi-Quellcode:

procedure TForm1.WndProc(var Msg: TMessage);
begin
  inherited;
  if Msg.Msg = 1125 then
    case msg.WParam of
      1: myInst.fillLvWithSl();   //Der FileExplorer Thread ist fertig, jetzt die Listview füllen.
    end;
end;

Jetzt ist mir leider noch nicht klar, warum die Nutzung eines Pointers für die StringList schlecht ist?
Klar kann ich auch eine Kopie der StringList übergeben, aber bedeutet das nicht mehr Rechenaufwand?
Es gibt nur diese eine Instanz der StringList die wie erwähnt ausschließlich durch den Thread erstellt und befüllt wird.
Danke für den Hinweis, dass Thread.Start nicht notwendig ist. Freue mich was zu lernen.


Liebe Grüße, Julian

[hoika]

Hallo,
man benutzt halt Pointer nicht, basta

Nein, warum so kompliziert, zumal Objekte intern eh auch nur Pointer sind.

Bei manchen Datentypen, z.B. Arrays kann es passieren, dass ein SetLength den internen Pointer ändert,
weil der Memory-Manager einen anderer, größerer Speicher benutzt und den aktuellen Inhalt des Arrays dort reinkopiert.
Die Array-Variable und der Programmierer bekommen davon aber nichts mit.

Dann wäre der andere gesicherter Pointer futsch und der Zugriff sorgt für "etwas" Ärger...