Zitat von Alex_ITA01:

Naja, es ist eine Form, die zu dem Thread "gehört" und auch nur dann erzeugt werden soll, wenn es den Thread gibt bzw. dieser erstellt wurde. Er soll sozusagen der "Owner" für das Form sein und hat auch seine entsprechenden Semaphoren und VCL Zugriffe auf die Form...

Form = GUI
Thread = Logik

Da man das -siehe Sir Rufo- nicht mischen soll, liegt hier ein Designproblem vor. Aber es ist schon klar, was Du bezwecken willst.

Führe dazu eine Klasse ein, die sowohl den Thread startet als auch das Formular sichtbar macht. Nennen wir die mal 'ThreadController'. Der Thread teilt dem ThreadController mit,

• wenn er gestartet wird => Form sichtbar machen
• wenn er beendet wird => Form unsichtbar machen
• wenn es etwas darzustellen gibt => Darstellen

Der Thread kann das über Synchronize-Aufrufe so steuern, das sich alles schön im Kontext des Mainthreads ausgeführt wird. Wenn der Thread das dann auch noch über Events löst, hast Du Form und Thread komplett entkoppelt, d.h. der Thread kennt die Form nicht, meldet aber per Event Änderungen an seinem inneren Zustand. Und der ThreadController sorgt dafür, das diese Änderungen in der Form landen.

Der Thread kann bzw. sollte nach außen hin komplett unsichtbar sein, d.h. Alles läuft über den ThreadController.

Zitat von Dejan Vu:

Zitat von Alex_ITA01:

Naja, es ist eine Form, die zu dem Thread "gehört" und auch nur dann erzeugt werden soll, wenn es den Thread gibt bzw. dieser erstellt wurde.

Form = GUI
Thread = Logik

Logisch ja, aber praktisch nein.

Ein "Window" (Form/Komponenten), welches per CreateWindow erstellt wird, wird mit dem Thread verbunden, in welchem es erstellt wurde.
Messages landen dann in diesem Thread und werden über dessen Nachrichtenbehandlung verarbeitet.

Darum landen bei der VCL auch PostMesssage, SendMessage und sonstige Events immer im Hauptthread.

Auf Seiten der Messages ist die VCL also threadsave, genauso, als wenn man es manuell über Synchronize machen würde.

Ok danke erstmal.
Die Aufrufe zum Form erfolgen auch komplett über Synchronize oder Events. Also entkoppelt ist es sowieso. Wollte aber das Form nicht immer erzeugen wollen im Hauptfenster, da ich den Thread evtl. bei dem einen Projekt benutze (also Form wird gebraucht) und in einem Projekt den Thread nicht drinne habe (Form wird also nicht gebraucht). Deswegen wollte ich dem Thread das Formular erzeugen und freigeben lassen, weil dieser ja weiß, wann werde ich benötigt und wann nicht.

Hat es denn irgendwelche Nachteile, wenn ich als AOwner=Application angebe und die manuelle Freigabe des Formulars bei mir rausnehme?

Viele Grüße

Es ist grundsätzlich nicht zu empfehlen das TForm der VCL in einem Thread zu nutzen, auch wenn es in dessen Kontext geschieht. Die VCL betreibt einfach zu viel non-thread-safe Gelumpe im Hintergrund. Du könntest aber durchaus mit der nackten WinAPI Fenster in einem Thread erzeugen, müsstest dann aber halt auch alles zu Fuß erledigen. Inklusive Nachrichtenschleife usw.
Was du da jetzt machst, ist eine ziemliche Verrenkung zwischen Haupt-(VCL-)Thread und einem anderen. Das wird vermutlich immer irgendwo knallen. Ich würde da eher dem Hauptthread signalisieren ein entsprechendes Fenster bei Bedarf zu erzeugen, und auch Werte die aus dem Thread stammen mittels Messages über den Hauptthread dort anzeigen - nicht mit dieser Synchronize-Krücke.
Ich würde deinen bisherigen Ansatz nicht weiter versuchen hinzufuckeln, das ist imho verschwendete Zeit.

Zitat von himitsu:

Zitat von Dejan Vu:

Form = GUI
Thread = Logik

Logisch ja, aber praktisch nein.

Praktisch auch JA. Denn es geht nicht um irgendeinen Thread, sondern um den ganz konkreten Thread des TE. Und der hat nun gar nichts mit der VCL am Hut. Sollte er mindestens.

Nur weil zufällig die VCL in einem Thread läuft, weil ja alles in einem Thread läuft, sollte man die Grundaussage der Trennung noch nicht mal im Ansatz in Frage stellen ('praktisch: Nein'). Das verwirrt doch nur unnötig.