Ahh ok habs kapiert.
Das geht leider nicht. Denn es gibt ja nicht nur den Thread TMeinThread. Es gibt noch eine weitere Unit die kein Thread ist.

Näheres kann ich aber erst sagen wenn ich mir später alles nochmal angucke.

Hält diese Unit zufälligerweise die selben Daten, wie auch der TMeinThread verarbeitet?

Das weiß ich gerade nicht aber es gibt ein anderes Problem.

meine erste Unit die TTheads = class und den constructor usw. enthält hat in der uses-klausel die Unit stehen die der eigentliche Thread ist.
In der Thread-Unit müsste ich dann auch wieder in die uses die Unit eintragen die TThreads enthält. Das geht leider nicht (zirkulär )

Mein Vorhaben ist also am Ende

Ich könnte das Problem umgehen, indem ich die Thread-Unit in die andere Unit, die den Thread erzeugt, verfrachte aber das will ich ehrlich gesagt nicht.

Genau. Das meinte ich vorhin. Daher mein Vorschlag, das zu verschieben. Was macht denn deine andere Klasse, die kein Thread ist (aber die dich vorhin hinderte die Liste von TThreads zu TMeinThread zu ändern)? Da lässt sich sicher nochwas verschieben.
Nichts ist am Ende

Verschieben in eine Unit geht ja auch nicht.

zusammenfalten · markieren

Delphi-Quellcode:

type
 TThreads class
 ...
 constructor Create(xyz: TMeinThread);
 itemX: TMeinThread;
end;

type
 TMeinThread = class(TThread)
 ...
 constructor Create(xyz: TThreads);
end;

TThreads braucht TThreads und TMeinThread braucht TThreads. Egal wie man es dreht und wendet.

Ich glaube ich bleibe einfach bei den zwei Variablen bevor ich hier jetzt alles komplett auseinander nehme.

Wie du meinst, aber warum kannst du die nicht in eine Klasse verschieben?

Siehe hier

zusammenfalten · markieren

Delphi-Quellcode:

type
 TThreads = class
 ...
 constructor Create(xyz: TMeinThread);
 itemX: TMeinThread;
 itemY: ....;
end;

type
 TMeinThread = class(TThread)
 ...
 constructor Create(xyz: TThreads);
end;

TThreads-constructor braucht TMeinThread, was unten drunter steht (geht nicht)
TMeinThread-contructor braucht TThreads, was oben drüber steht (das geht).

Und egal wie ich es wende, irgendeine der beiden Klassen braucht immer irgendwas was nicht zur Verfügung steht.

Ich könnte ja auch, wie du sagtest, TThread wegmachen und nur TMeinThread in der ObjectList verwenden aber dann habe ich echte Threads rumliegen die man ggf. gar nicht braucht.

Weil nicht jeder ListView-Eintrag braucht einen Thread (itemX). Manche brauchen auch nur ein itemY, was kein Thread ist.


Edit habe gerade nachgeguckt. itemY ist auch ein Thread aber in keinster Weise wie der von itemX.
Ich könnte irgendwie beide Thread-Units zu einer verschmelzen und dann im Konstruktor bestimmen, welcher Code in der Execute-Methode ausgeführt wird aber mhh..

Stelle dir vor, du hättest ein TData Objekt. Nur mal so als Gedankenspiel...
Dieses TData könnte die Daten halten, die du für deine ListView brauchst. Stelle dir vor, dass manche TData Instanzen in Wahrheit einfach vom Typ TMeinThread sind. Andere Instanzen (die, die keinen Thread brauchen) von TData sind in Wahrheit von einem anderen Typ. Stelle dir vor das ginge. Würde dir das helfen?

Edit: Du könntest auch beide Threads von der selben Basisklasse erben lassen und dann in der Liste einfach deinen Basisklassentyp setzen. Die beiden Kindthreadklassen dieser Basisklasse haben dann einfach unterschiedliche Execute Implementierungen.
Konkret: TMeinBasisThread erbt von TThread, TMeinXThread erbt von TMeinBasisThread, TMeinYThread erbt von TMeinBasisThread; ThreadList enthält Typen von TMeinBasisThread und TMeinBasisThread enthält alle wichtigen Felder, die du für die ListView brauchst.

Entweder ist es spät, oder ich bin einfach nur dumm. Denn verstanden habe ich kein bisschen
Ich lasse einfach erstmal alles so wie es ist.

Ich tippe auf zu spät. Wenn du magst, können wir das gerne vertagen. Ich würde da noch nicht aufgeben an deiner Stelle. Geduld zahlt sich aus
Schlaf gut!

Brighty