Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Christian H. Kuhn" Newsgroups: de.comp.lang.java Subject: =?UTF-8?Q?GUI-Update_=c3=bcber_Swing-EDT_=28was:_JUnit_Test_von_JBu?= =?UTF-8?Q?tton:_Action_wird_nicht_erkannt=29?= Date: Fri, 15 Jul 2016 12:03:13 +0200 Lines: 46 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net nWIWoolifAW2lvcEwyYzQQtiJMLxKvVTUYpAEzR+tOGNf6fF0= Cancel-Lock: sha1:2Pc7B5zpBGFjfVVc0QKBtN549LY= User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: Xref: csiph.com de.comp.lang.java:12992 Topic adapted. Am 14.07.2016 um 19:47 schrieb Patrick Roemer: > Responding to Christian H. Kuhn: > Das muss alles über den Swing-EDT laufen. Ich habe ne Nacht drüber geschlafen. Und die Doku zu SwingUtilities gelesen :-) Um herauszufinden, was wie arbeitet, lasse ich das GUI-Modell als autonomous view mal unangetastet. Ja, presentation model ist besser und kommt auch noch. Ein Schritt nach dem anderen. Aufrufe zur Änderung des GUI-Zustands aus den Tests können mit SwingUtilities.invokeAndWait() auf den Swing-EDT gelegt werden. QChessClock greift auf die GUI ausschließlich per notifyObservers() und darin implementiert über die verschiedenen update() zu. QChessClock weiss nichts über die Art seiner Oberfläche. Deshalb kommt ein Aufruf von notifyObservers() (sowieso nicht, ist zu lang und zu komplex und könnte den EDT blockieren) oder der einzelnen update() per invokeAndWait() nicht infrage. QChessClockJavaAVTest greift nur an einer Stelle anders als per notifyObservers() direkt schreibend auf die GUI zu. Die Stelle ist auf invokeAndWait() geändert. Alle anderen Schreibzugriffe erfolgen über notifyObservers(). Die Testklasse darf wissen, dass das Testobjekt in Swing realisiert ist; es wäre möglich, notifyObservers() (eher nicht, s.o.) oder update() mit invokeAndWait() aufzurufen. Da das Problem aber ohnehin in der GUI gelöst werden muss, s.o., brauche ich am Test nichts zu ändern. Ich merke, dass ich immer noch in der Vorstellung lebe, dass Objekte und mit ihnen alle ihre Eigenschaften und Methoden in einem Thread leben. Für Objekt und Felder mag das gelten, Methoden leben aber in dem Thread, der sie aufruft. Das übersehe ich gerne. In QChessClockJavaAV betrifft das die verschiedenen update()-Methoden. Die werden nicht unbedingt in dem Thread ausgeführt, in dem die GUI angelegt wird. Und selbst wenn: Sie verändern den GUI-Zustand und gehören daher in den Swing-EDT. Also ändere ich alle update()-Methoden so, dass sie ihre Schreibzugriffe über invokeAndWait() ausführen. v0.8.5 Die Zeitprobleme kommen extra. lg QNo