![]() |
Formulare und Threads
Hi @all,
ich habe ein Problem mit Formularen und anderen Threads als dem Hauptthread. Ist es so, dass man Formulare nicht aus anderen Threads heraus erzeugen bzw. anzeigen kann? Ich habe eine Multi-Monitor-Anwendung geschrieben, in der man für jeden verfügbaren Bildschirm bestimmen kann, ob auf diesem etwas angezeigt wird und was angezeigt wird. Dazu baue verwende ich ein dynamisches Array aus Formularen. Hier mal etwas Code:
Delphi-Quellcode:
Dass ich die Formulare jedesmal neu aufbaue, hängt damit zusammen, dass das Programm im Hintergrund laufen soll, bedient wird es über Konfigurationsdateien und Netzwerkbefehle. D.h. die Anzahl der Formulare kann zur Laufzeit geändert werden.
var TVForms : array of TForm;
//... procedure FreeForms; var x : integer; begin for x := 0 to High(TVForms) do TVForms[x].Free; SetLength(TVForms, 0); end; procedure TFormThread.Execute; var x : integer; begin while not(terminated) do begin //Falls bereits vorhanden, evtl. "alte" Formulare zerstören (ab dem 2. Schleifendurchlauf) FreeForms; SetLength(TVForms, {les ich aus ner Konfiguration aus, kann jederzeit geändert werden}); for x := 0 to High(TVForms) do begin // Hier geht's nicht weiter! TVForms[x] := TForm.create(nil); //... Mache irgendwas damit end; Sleep(15000); end; end; Ich hoffe, ihr versteht, was ich meine. Danke schonmal. Gruß Michael |
Re: Formulare und Threads
Herzlich willkommen in der DelphiPraxis! :hi:
Erstmal etwas grundsätzliches zu Threads und Forms: Jeder Thread darf sich ohne Synchronisierung nur um seine eigenen Forms kümmern. Dazu ein Zitat aus meinem Post im Delphi-Forum: Zitat:
|
Re: Formulare und Threads
Erstmal danke für deine Antwort.
Nun zu der Sache mit dem Synchronisieren: Ich greife mit dem Hauptthread gar nicht auf die Formulare zu. Ich wollte sie mit dem Hintergrund erstellen, modifizieren, anzeigen und auch wieder freigeben. Das ganze sollte automatisch geschehen. Der Benutzer sieht das Hauptformular mit dem VCL-Thread meistens gar nicht --> Also keine Klicks etc. Der Hintergrundthread soll ganz unabhängig arbeiten (Konfiguration einlesen, alte Formulare freigeben, erforderliche Formulare ermitteln, Daten lesen, verarbeiten, Formulare erstellen, Daten anzeigen). D.h. da muss eigentlich nichts synchronisiert werden. Ich hab da so 'ne Vermutung, ich weiß halt nicht, ob sie stimmt: Und zwar könnte es sein, dass Delphi beim Erstellen bzw. Anzeigen eines Formulars das Formular beim VCL-Thread "anmeldet", damit über diesen auf Formular-Ereignisse zugegriffen werden kann. Wäre es vielleicht möglich, dass man dies verhindert, da ich ja die Formulare nur zum Anzeigen von Daten benutzen will? Vielleicht hat ja einer von euch noch ne Idee. Wie gesagt, diese Formulare dienen rein der Ausgabe. Sie sollten also irgendwie nicht auf Benutzerereignisse warten, falls das irgendwie zu machen ist. Bitte um weitere Vorschläge. Vielen Dank. |
Re: Formulare und Threads
Zitat:
Das Formular muss sich ja auch mit anderen Dingen rungsherum noch absprechen (Fensterhandler etc.). Also jede Aktion auf ein Formular muss synchronisiert werden. Aber mach doch einfach folgendes: In den Formularen lass einen Timer laufen, der alle x-Millisekunden die Daten auf dem Formular aktualisiert. Die Daten lässt du vom Thread in einem Objekt bereitstellen. Also bildhaft gesprochen: Der Daten-Beschaffungs-Thread macht Daten-Beschaffung und speichert dies in einem Objekt und der Anzeige-Thread (also das Formular) kümmert sich auch nur um die Anzeige ;-) cu |
Re: Formulare und Threads
Soviel ich weiß dürfen VCL-Controls nur im Hauptthread erzeugt werden. Es bringt nicht wenn das Komplette Formular im Thread erzeugt wird da interaktionen mit dem TApplication-Objekt und der MessageQueue im Hauptthread erfolgt.
Eine Möglichkeit wäre (mit entsprechenden COM-Nachteilen) diese Formulare in eine kleine COM-Komponente auszulagern. Da diese auch im Thead erzeugt werden darf und diese Komponente ein eigenes Application-Objekt hat dürft da nichts passieren. Auch die verlagerung in eine DLL mit eigener DLL-Application-Instanz könnte das Problem lösen. Bei DLL darfst Du vermutlich nicht mit Laufzeitpackages arbeiten. |
Re: Formulare und Threads
Danke für die Antworten.
@Sir Rufo: Das hätte ich auch alles gemacht, WENN ich vorher wüsste, wieviele Formulare ich brauche. Das allerdings wird erst vom Daten-Beschaffungs-Thread (*g*) festgelegt, weil der aus den Daten herausliest, wieviele Formulare benötigt werden. Also is prinzipiell nur dieser Thread in der Lage, die Formulare zu erzeugen, da nur er die nötigen Informationen dazu besitzt. @Bernhard Geyer: Das wäre mal ein Versuch wert. An DLLs hab ich aus anderen Gründen in dem Zusammenhang schon gedacht. COM-Komponente wäre in dem Fall wie mit Kanonen auf Spatzen geschossen. |
Re: Formulare und Threads
Zitat:
Genauso kann man auch die Löscheng des Forms wieder veranlassen, einfach einen Flag in den Daten, ob ein Form angezeigt werden muss oder nicht. Form-Pointer auf NIL=kein Formular angelegt, Form-Pointer <> NIL=Form is da und wird gefreeeeet wenn nötig. cu |
Re: Formulare und Threads
Das wäre so ein Gedanke, sofern das mit dem Timer funktioniert (wobei ich mir da nicht sicher bin, denn ein Timer stellt ja auch nur einen neuen Thread dar). Ansonsten bin ich soweit wie vorher, da niemand da is, der neue Formulare dynamisch erzeugen kann (Das Hauptformular macht - wie schon gesagt - gar nix).
|
Re: Formulare und Threads
Aber es ist schon gut. Wenn's ne einfache Möglichkeit gegeben hätte, Formulare genauso wie andere Variablen in Hintergrundthreads zu verwenden, dann wär's ok gewesen. Ihr braucht euch jetzt nicht den Kopf zu zerbrechen. Ne etwas umständliche Möglichkeit hab ich bereits in Gebrauch. Dabei wird der Hintergrundthread unterbrochen, wenn über Netzwerk ein Befehl zum Reinitialisieren der Daten kommt, dann werden die Daten im Vordergrund gelesen, die Fenster erzeugt und der Hintergrundthread wird fortgesetzt.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 09:49 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz