Was möchtest du denn tun? Bzw was ist dein Ziel?

Ich versuche noch immer zu verstehen, was genau dein Problem ist.

(totally unrelated zu Interfaces: Ich glaube, dass du grundsätzlich das Prinzip von Interfaces schon verstanden hast, wenn du ein bisschen Objektorientierung verwendet hast; Interfaces sind nichts anderes als Klassen ohne Implementierung. Habe keine Angst davor! Der Vorteil ist nur, dass du manchmal flexibler bist; Die effektive Verwendung von Interfaces führt oft einfach dazu, dass dein Modell weniger stark zusammenhängt. Ich glaube aber dein Problem sitzt in dem Fall aber wo anders...)

Zitat:

Aber ohne Interfaces

Er will es nicht und hat es auch schon in anderen Threads gesagt.
Lasst ihm seinen Willen

Ist ja auch nicht weiter tragisch.

gruss

Mein Ziel grob erklärt:

mein hat eine ListView und jede ListView ist ein Datensatz. Jeder, ich nenne es mal "Eintrag", kann einen Thread im Hintergrund laufen haben, muss aber nicht.

Wenn aber ein Thread im Hintergrund für einen Eintrag laufen soll, dann wird meiner ObjectList über Add eine Instanz von TThreads übergeben.
Im Create von TThreads wird der eigentliche benötigte Thread erzeugt.

Über aThreadInfo.ThreadList.Items[i].itemX kann ich nun auf meinen Thread zugreifen. Über aThreadInfo.ThreadList.Items[i].VARIABLEXYZ auch auf Variablen der Klasseninstanz selber (nicht des Threads, der Thread ist itemX).

Ich möchte nun, dass mein Thread itemX auf Variablen der Klasseninstanz zugreifen kann, dem er (der Thread) angehört.

Aktuell haben bei mit itemX und itemY jeweils eine Variable, die den gleichen Zweck erfüllen. Deswegen dachte ich packe ich die in die Klasseninstanz dann habe ich nur noch eine.

Beispiel: aThreadInfo.ThreadList.Items[i].itemX.bPause würde den Thread (itemX) dann pausieren (setter). Hier wäre es aber besser eine einzige Variable zu haben, die ich aus beiden Teilen, itemX und itemY, abrufen kann.

Zitat:

Er will es nicht und hat es auch schon in anderen Threads gesagt.

Grund ist ganz einfach, dass ich Interfaces nicht verstehe und Code den ich nicht verstehe möchte ich nicht einbauen

Wenn ich dich richtig verstanden habe, möchtest du innerhalb eines Threads auf ein Set von Variablen zugreifen, die für diesen Thread zur Abarbeitung seiner eigenen Tätigkeit wichtig sind. Was hindert dich daran, bei der Initialisierung des Threads diesen "Kontext", also eine Referenz auf dein übergeordnetes Objekt diesem zu übergeben? (also eine Referenz auf dein jeweiliges TThreads)

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.