Von ThreadA erzeugtes VCL-Objekte von ThreadB freigeben

[s.h.a.r.k]

Ich muss mich euch dann wohl geschlagen geben Aber das kostet mich nun wieder viel Zeit alles zu ändern... Die Welt ist grausam

[himitsu]

Du kannst notfalls mit DLLs arbeiten.

Jedes "getrennte" Fenster in eine DLL.


DLLs haben ja ihre eigene VCL, welches ja grad verhindert, daß man schlecht über EXE/DLL-Grenzen hinweg an gemeinsamen Fenstern arbeiten kann, aber getrennte Fenster lassen sich dafür dann besonders gut verwalten

[s.h.a.r.k]

Hm, das ist ein guter Einwand, den ich mir für die Zukunft merken kann. Aber ich liefere gerne nur Exen aus, da ich es hasse, wenn ein Programm mit mehreren hundert Dateien daher kommt und eigentlich nur minimal Aufgaben hat

[himitsu]

Zitat von s.h.a.r.k:

Aber ich liefere gerne nur Exen aus, da ich es hasse, wenn ein Programm mit mehreren hundert Dateien daher kommt und eigentlich nur minimal Aufgaben hat

Mach ich auch gern.

Tjs, dann mußt du eben alle Fenster synchronisiert über den Hauptthread verwalten.

[s.h.a.r.k]

Da stellt sich mir dann überhaupt die Frage, was ich dann mit Objekten innerhalb eines Thread machen darf?! ich kann ja nie garantieren, dass eine Methode eines beliebigen Objekts nicht doch irgendwas mit einem VCL-Objekt zu tun hat.

Darf ich z.B. Daten aus der Datenbank laden? Pauschal gesagt, doch eigentlich nur synchronisiert, oder? Und dann bringt es mir doch nichts, das Startupprozedere in einen Thread auszulagern, sodass, wie in meinem Beispiel, eine sichtbare Animation flüssig läuft und die Anwendung bedienbar bleibt, da ja das Laden dann ja im MainThread läuft, da synchronisiert wird.

Oder sehe ich daran irgendwas falsch?

[wicht]

Hi!

Zitat:

Da stellt sich mir dann überhaupt die Frage, was ich dann mit Objekten innerhalb eines Thread machen darf?! ich kann ja nie garantieren, dass eine Methode eines beliebigen Objekts nicht doch irgendwas mit einem VCL-Objekt zu tun hat.

Doch, das musst du können. Wenn ich z.B. einen Thread TFileParseThread habe, übergebe ich den Dateinamen und eventuell Parameter an den Thread, der erstellt sich einen TFileStream, benutzt ihn, und gibt ihn wieder frei. Kein VCL-Zugriff. Die Ergebnisse reicht der Thread dann nach längerer Arbeit kurz an den Haupt-Thread durch, welcher dann die Eigenschaften der Grafischen Komponenten setzt, je nach Daten, die der Thread mitgeteilt hat. Irgendwelche (visuellen) Objekte von der Form haben in einem Thread halt nix zu suchen.

Zitat:

Darf ich z.B. Daten aus der Datenbank laden? Pauschal gesagt, doch eigentlich nur synchronisiert, oder?

Du meinst, weil du eine SQLConnection-Komponente (oder wie es heißt) im Form hast und diese an den Thread weiterreichst? Entweder solange wie der Thread läuft dem Form den Zugriff auf die Komponente verbieten oder aber im Thread eine eigene Verbindung aufbauen (nicht Objekt von Form mitgeben, sondern TSQLConnection direkt im Thread erzeugen). Oder dir einen Connection-Pool bereit halten. Oder, oder... Die Beschränkung, nicht auf VCL-Dinge zuzugreifen, gilt glaube ich nur für Komponenten, die was malen, wie Labels halt zum Beispiel. Allerdings sollte man dabei vorsichtig sein, z.B. könnte ein Event von solchen Dingern dann ein anderes VCL-Teil ansprechen. Und es ist irgendwie sehr unschön, Sachen der Form weiterzugeben an einen Thread.

Am Anfang ist das mit den Threads aller etwas mühselig und auch wenn man diese Problem gemeistert hat werden noch einige andere kommen. Wenn es dann aber irgendwann funktioniert, fühl sich das schon gut an