windows.forms: Panel aus anderem Thread-Kontext ansprechen
-
Hi,
ich habe hier ein Panel, das aus dem Mainthread heraus erzeugt und meiner Oberfläche hinzugefügt wurde. Der Inhalt des Panels selber wird dynamisch innerhalb eines eigenen Threads generiert und dann dem Panel hinzugefügt.
Zu meiner mehr als großen Überraschung ist das bei .NET keine threadsichere Operation und wirft mir eine Exception um die Ohren.
Nur: wie kann ich das umgehen, sprich wie kann ich meinem Panel dennoch diverse UI-Elemente hinzufügen?
-
TomoT schrieb:
Zu meiner mehr als großen Überraschung ist das bei .NET keine threadsichere Operation und wirft mir eine Exception um die Ohren.
Welche Sprache kann das denn? Würde mich mal interessieren.
Zu deiner Frage. Du kannst mit Control.BeginInvoke eine Methode aufrufen mit welcher du den Threadübergreifenden Aufruf durchführen kannst.
-
Die .NET Forms sind da ziemlich hardcore, die lassen dich bestimmte Dinge gar nicht aus nem anderen Thread machen.
D.h. du kannst Control.Invoke verwenden, oder die Initialisierung gleich im "richtigen" Thread machen.
-
Firefighter schrieb:
Welche Sprache kann das denn? Würde mich mal interessieren.
Mit Java/Swing ist mir das Problem bisher nicht aufgefallen. Dass es andere Toolkits nicht können, die direkt in C/C++ programmiert sind und auf Betriebssystemfunktionen zugreifen, ist für mich verständlich. Aber auf einer so weit abstrahierten Ebene wie das Swing und windows.forms sind bzw. sein sollten, erstaunt mich das doch ein wenig (da kommen ja nicht mal mehr die Threads aus dem OS, sondern aus einem RT-eigenen Scheduler, also kann man sich da von diesem Problem lösen).
-
hustbaer schrieb:
D.h. du kannst Control.Invoke verwenden, oder die Initialisierung gleich im "richtigen" Thread machen.
Invoke() funktioniert, Danke.
-
TomoT schrieb:
Mit Java/Swing ist mir das Problem bisher nicht aufgefallen.
Dann hattest du bisher Glück. Swing ist nicht threadsicher.
http://download.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.htmlThis is necessary because most Swing object methods are not "thread safe"
TomoT schrieb:
Aber auf einer so weit abstrahierten Ebene wie das Swing und windows.forms sind bzw. sein sollten, erstaunt mich das doch ein wenig (da kommen ja nicht mal mehr die Threads aus dem OS, sondern aus einem RT-eigenen Scheduler, also kann man sich da von diesem Problem lösen).
Soweit mir bekannt ist, verwenden .Net und Java die Threads aus dem OS. Früher einmal hatte Java eigene Threads, doch das ist inzwischen Vergangenheit. Aber auch wenn sie einen eigenen Scheduler hätten, man müsste trotzdem irgendwo synchronisieren. Ein GUI threadsicher zu erstellen ist eine sehr mühsame Sache und macht im allgemeinen die GUIs noch langsamer, als sie sowieso schon sind.
Im übrigen, Windows.Forms bildet nur die WinAPI Möglichkeiten ab. Das sind grundsätzlich alles Wrapper um die WinAPI.
Grüssli
-
Dravere schrieb:
Dann hattest du bisher Glück. Swing ist nicht threadsicher.
Keine Glückssache:
"Swing event handling code runs on a special thread known as the event dispatch thread. Most code that invokes Swing methods also runs on this thread."
D.h. man landet dort in den allermeisten Fällen sowieso im richtigen Threadkontext (es sei denn, man zwingt sich mit Gewalt in einen unerlabten State) - und der Rest fällt einem mit besagten Exceptions/Fehlern relativ schnell um die Ohren.
-
TomoT schrieb:
Keine Glückssache:
"Swing event handling code runs on a special thread known as the event dispatch thread. Most code that invokes Swing methods also runs on this thread."
D.h. man landet dort in den allermeisten Fällen sowieso im richtigen Threadkontext (es sei denn, man zwingt sich mit Gewalt in einen unerlabten State) - und der Rest fällt einem mit besagten Exceptions/Fehlern relativ schnell um die Ohren.
Dann hast du aber nie mit eigenen Threads in Swing gearbeitet. Ich bin davon ausgegangen, dass du genau dies hast. Auch mit
Windows.Forms
arbeitet man in den allermeisten Fällen im richtigen Threadkontext.Grüssli