Im Grunde ist das mit den Threads recht einfach, vor allem wenn man TThread als Basis nimmt. Kurzform: Alles was in der überschriebenen Methode "Execute()" passiert bzw. da heraus aufgerufen wird, passiert in einem eigenen Thread. Bamms. Abgesehen davon ist ein TThread-Nachfahre eine Klasse wie jede andere auch.
Was das ganze etwas verkompliziert, ist das Zusammenspiel mehrerer Threads, so z.B. mit dem Hauptthread deiner Anwendung, in dessen Kontext u.a. alles was mit der
VCL GUI zu tun hat läuft. Da kommen dann so Spiele wie Synchronisation hinzu. Als einfachst-mögliche Fausregel könnte man eventuell sagen: Nutze in einem Thread niemals Dinge, die nicht innerhalb des Threads erstellt wurden. "Innerhalb des Threads" heisst bei TThread, dass es entweder in dessen Kontruktor, oder der Execute-Methode.
Gemein ist dabei, dass es an sich prinzipiell geht, und 1000 Mal auch ohne Probleme, aber auch das wir einem eines schönen Tages in den Hintern beissen. Daher gleich rigoros sein, und nicht "rumhacken".
Sobald man mit anderen Threads kommunizieren will (z.B. einem
VCL Control eine StringList unterjubeln), muss man threadsichere bzw. threadsichernde Wege wählen, wozu das direkte Beschreiben von Properties (oder aufrufen von Methoden)
nicht zählt, es sein denn, man tut dies in einer Critical-Section (TCriticalSection), die die beteiligten für die Dauer der Operation zusammenführt.
Alternativ, und das ist mein Favorit, Windows-Messages vom Thread an ein Formular schicken, und dort dann mit einem Handler reagiern.
Btw: Schön, dass wir dich doch noch zur "Wurzelbehandlung" an der
DB bekommen haben - das beruhigt meinen Magen
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)