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
