Thread: Direkt auf die Form zugreifen?

[Helmi]

Hallo,

mich würde es interessieren was ihr dazu denkt:

Ich habe einen Thread der eine for-Schleife hat.
In dieser Schleife wird von einer ListView die Zeilen nacheinander abgearbeitet und die einzelnen Spalten ausgelesen.
Die ListView liegt auf der Form1.

Ich würde gerne das so umbauen, dass der Thread nicht direkt auf die Form1 und somit direkt auf die ListView zugreifen muss, sondern ich würde gerne dem Thread vor dem Starten die ListView irgendwie übergeben.

Ich hab schon an eine StringList etc. gedacht, die ich vor dem Starten des Threads mit den aktuellen Inhalten der ListView beschreibe, aber ich benutz auch die CheckBoxen der ListView. Diese werden auch in der Schleife abgefragt.

Was meint ihr?
Ist es in Ordnung, dass der Thread in der Schleife auf die Form1 zugreift oder wie würdet ihr das machen?

P.S.: ich hoffe ihr wisst was ich mein.

[edit] Titel vergessen :wall:

[jfheins]

Zitat:

Zitat von Helmi

Ist es in Ordnung, dass der Thread in der Schleife auf die Form1 zugreift ?

Wenn die ListView ein Element der VCL ist, was ich mal annehme, dann ist das nicht in Ordnung.

Dann müsstest du in dem Thread eine ListView unterbringen, und deine ListView beim Start kopieren ...

[SirThornberry]

oder einfach eine TList nehmen und mit records der gewünschten daten füllen.

[Helmi]

Wie meinst du das mit der TList?

hab mit der noch keine Erfahrung.
Kann ich bei der auch ne CheckBox übergeben?

[Helmi]

Hallo Jungs,

ich hab mich jetzt doch entschieden eine 2. ListView (nicht visuell) zu benutzen
(genauer gesagt es war ein Tip eines C++-Programmieres)

Jetzt hätt ich dazu noch ne frage:
Wo soll ich jetzt diese ListView erzeugen?
In der Form1? - bei OnCreate und bei OnDestroy wieder freigeben?

oder im Execute des Threads am Anfang erzeugen und am Ende wieder freigeben?

[Michael_Bayer]

Zitat:

Zitat von jfheins

Zitat:

Zitat von Helmi

Ist es in Ordnung, dass der Thread in der Schleife auf die Form1 zugreift ?

Wenn die ListView ein Element der VCL ist, was ich mal annehme, dann ist das nicht in Ordnung.

Dann müsstest du in dem Thread eine ListView unterbringen, und deine ListView beim Start kopieren ...

Woran liegt da das Problem? :gruebel:

Ich habe auch viele Threads, die aktiv an Elementen auf meiner Form rumschmieren - ist das nicht okay?

[Kedariodakon]

Eigendlich nicht :roll:
Meist geht sowas gut, aber sobald da ein Pentium mit HT oder nen REchner mit Dual Prozis dazukommt geht nix mehr, obwohl, Fehlermeldungen gehen noch :zwinker:


Bye

[Mephistopheles]

Das hat etwas mit Synchronisation zu tun. Selbst wenn es ein Uniprocessor-System ist, auf dem es nur eine quasi-parallele Abarbeitung der Threads gibt, kann es passieren, daß ein Thread Speicher freigibt/-gab und während ein anderer versucht darauf zuzugreifen. Bei Objekten wird das ganze noch viel komplexer und ist irgendwann unüberschaubar.

Daher sollte man entweder Ausschlußobjekte (z.B. Mutexe, Semaphoren, Critical Sections) benutzen um jeweils nur einem Thread Zugriff zu gewähren oder bei 32bit(bzw. Bitzahl der CPU)-großen Einzelwerten die Interlocked*-Funktionen verwenden. Alles andere ist nicht nur unsauberer Programmierstil sondern kann auch Multi-Processor-Systemen (oder auch HT-Systemen, bei sind ja im Kommen) zu bösen schwer nachvollziehbaren Fehlern führen. Also Finger weg von der VCL aus Threads heraus. Sauberer Stil ist sowieso, daß der Thread nur ein Fenster benachrichtigt und dieses Fenster dann die Daten von einer vorher vereinbarten Stelle abholt. Danach wird dem Thread wieder signalisiert, daß er auf diese Stelle wieder schreiben darf usw. usf.

[Helmi]

Hallo,

ich hab mir das so vorgestellt:
(wenn was zum aussetzen ist, bitte melden)

In dem Thread-Execute mach ich folgendes:

Delphi-Quellcode:

procedure TUpdatethread.Execute;
begin
  try
    //Thread-ListView erzeugen
    Thread_ListView := TListView.Create;

    Synchronize(CopyListView);

    Updaten;

  finally
    //Thread-ListView freigeben und löschen
    FreeAndNil(Thread_ListView);
  end;
end;

die Procedure "CopyListView" schaut so aus:

Delphi-Quellcode:

procedure TUpdatethread.CopyListView;
begin
  Thread_ListView.Assign(Form1.ListView_Dateien);
end;

kann man das so lassen oder gibts was auszusetzen?

[Michael_Bayer]

Zitat:

Zitat von Mephistopheles

Das hat etwas mit Synchronisation zu tun. Selbst wenn es ein Uniprocessor-System ist, auf dem es nur eine quasi-parallele Abarbeitung der Threads gibt, kann es passieren, daß ein Thread Speicher freigibt/-gab und während ein anderer versucht darauf zuzugreifen. Bei Objekten wird das ganze noch viel komplexer und ist irgendwann unüberschaubar.

Daher sollte man entweder Ausschlußobjekte (z.B. Mutexe, Semaphoren, Critical Sections) benutzen um jeweils nur einem Thread Zugriff zu gewähren oder bei 32bit(bzw. Bitzahl der CPU)-großen Einzelwerten die Interlocked*-Funktionen verwenden. Alles andere ist nicht nur unsauberer Programmierstil sondern kann auch Multi-Processor-Systemen (oder auch HT-Systemen, bei sind ja im Kommen) zu bösen schwer nachvollziehbaren Fehlern führen. Also Finger weg von der VCL aus Threads heraus. Sauberer Stil ist sowieso, daß der Thread nur ein Fenster benachrichtigt und dieses Fenster dann die Daten von einer vorher vereinbarten Stelle abholt. Danach wird dem Thread wieder signalisiert, daß er auf diese Stelle wieder schreiben darf usw. usf.

Hmm..würde das so funktionieren, dass ich ein globales Array aufbaue und dem Thread mitgebe, er soll in Array[1] die Lösung stecken, wenn er fertig ist?

Oder nochbesser: Kann ich dem Thread sagen, es soll die Lösung in eine Procedure als Parameter übergeben, und die Procedure ändert dann die VCL?

Oder muss ich das so machen, dass ich eine globale Variable Editable mache, die ich auf false setze, wenn ein Thread gerade ein VCL-Element ändert?