Zitat:

Wenn ich dich richtig verstanden habe, (...)

Hast du. Da ich exakt eine Variable pro Klasseninstanz aber in 2 Unterklassen brauche, habe ich aktuell pro Unterklasse eben diese Variable 1x.

Zitat:

(also eine Referenz auf dein jeweiliges TThreads)

Wenn man das machen darf, hört sich das gut an!

Ehrlich gesagt habe ich da jetzt nur spontan Pointer und Const im Kopf. Aber das ist es nicht, was du ansprichst, oder?

Woran ich auch gedacht habe ist, dem Thread eine ID mitzugeben (die ID des "items[i]"). Aber das würde mich sehr einschränken was Änderungen an den ObjectList-Items, also den Klasseninstanzen, angeht.

Du kannst deinem Thread übergeben was dir beliebt. Es ist ja dein Programm
Oder dein TMeinThread hat eben entsprechende (u.U. private) Felder, die im Construktor mit übergeben werden, auf die du dann von Execute aus Zugriff hast.
Wenn die Variablen auch nur dort relevant sind, kannst du diese vielleicht auch aus TThreads dorthin verschieben und dann auch von dort darauf zugreifen?

Vermute ich das richtig, dass deine Referenz itemX auf deinen Thread in TThreads nur deshalb existiert, damit du diesen noch von außen abbrechen kannst/den Status rausfinden kannst? Existieren TThreads Einträge in deiner Liste, deren itemX nil ist?

Brighty

itemX ist die Instanzvariable des Threads und mit aThreadInfo.ThreadList.Items[i].itemX.bPause lege ich den Thread schlafen (ich prüfe einfach auf while bPause do ... (bPause, property, Boolean steht in der Unit des Threads)

Habe gerade das hier gefunden und gucke es mir gleich mal an.
http://stackoverflow.com/questions/3...-pass-by-value

Demnach kann ich dann ja ... ok muss ich gleich gucken wenn ich wieder eine IDE habe.. gucke ich gleich welches Object ich als Parameter übergeben kann.


Edit.

wenn ich den constructor habe

markieren

Delphi-Quellcode:

constructor TThreads.Create(...);
begin
...
 itemX := TMeinThread.Create(...); // <== HIER
...
end;


aThreadInfo.ThreadList.Add(TThread.Create(...));

Da müsste ich dann ja die Referenz übergeben. Wäre das hier, haut mich nicht.. aber wäre das nicht "Self" (constructor)?

Ah. Ich wusste unser Problem liegt wo anders
Ja, also wenn du ganz klassisch (so wie bei einem ganz normalen Funktionsaufruf, in Konstruktoren, ...) ein Objekt mit übergibst, dann ist das nur eine Referenz auf dieses Objekt. Intern übersetzt dir dein Compiler das oft einfach nur in Pointer auf das Objekt. Also genau wie indem stackoverflow Beitrag beschrieben... Dich hindert niemand daran, diese Referenz in mehreren Instanzen oder/und in mehreren Feldern zu halten. Nur aufpassen beim Free usw: Wenn du natürlich das Free auf einer dieser Referenzen aufrufst, dann werden die anderen logischerweise auch davon betroffen sein!

Brighty

Edit: genau. TMeinThread.Create braucht halt im Konstruktor noch entsprechend den Parameter. Was du hier aber jetzt machst ist das klassische Beispiel einer zirkulären Referenz: dein TMeinThread kennt TThreads und TThreads kennt TMeinThread. Wenn du das auflösen willst, sag bescheid; da gibt es einen kleinen Trick.

Ok nur um das festzuhalten:
"Self" im Konstruktor bezieht sich auf den Konstruktor/das durch den Konstruktor erzeugte Objekt selber.

Und im Konstruktor itemX := TMeinThread.Create(...); aufrufen würde mir in der Thread-Instanz ItemX dann eine Referenz auf das TThread zur Verfügung stellen?

TThreads; Nicht nur im Konstruktor. Innerhalb einer Methode, Funktion, Destruktor, ...

Ich teste das gleich mal schnell. Sollte ja nur eine Tipparbeit von 1 Minute sein (neuer Parameter) und ein showmessage in der Thread-Unit zum Test.

Die spannende Frage verbleibt: Wenn deine TThreadInfo.ThreadList nur diejenigen Einträge deiner ListView Einträge hält, die grade einen Thread benötigen; Brauchst du dann TThreads als Klasse wirklich? Oder könntest du nicht dann auch den Typ deiner ThreadList einfach auf TMeinThread ändern und einfach alle itemY, itemZ, itemQ, itemA,.... Felder in deine TMeinThread Klasse verschrieben und TThreads wegrationalisieren?
(Kenne den Rest des Programms nicht...)

TMeinThread ist schließlich auch nur eine ganz stinknormale Klasse, die einfach nur von TThread erbt. Nichts besonderes also; die kann ganz normal Methoden und Felder bekommen, wenn sie mag...

Brighty

Demnach könnte ich dann mein Konstrukt

markieren

Delphi-Quellcode:

type
 TThreadInfo = packed record
  ThreadList: TObjectList<TThreads>;
  iThreadID: Cardinal;
  ThreadHandle: THandle;
 end;

entfernen. Die Variablen iThreadID und ThreadHandle benutze ich so oder so nirgendwo.

Oder habe ich etwas falsch verstanden?

... und aus

ThreadList: TObjectList<TThreads>; würde

ThreadList: TObjectList<TMeinThread>; , wenn du alle anderen Felder außer itemX nach TMeinThread verschieben würdest (itemX fiele ganz weg in dem Fall).

Wenn du soweit bist und damit zufrieden bist, könnten wir eventuell nochwas anderes ansprechen, wenn du magst