Path: csiph.com!feeder.erje.net!2.eu.feeder.erje.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.xdsl-84-44-179-215.netcologne.de!not-for-mail From: Patrick Roemer Newsgroups: de.comp.lang.java Subject: =?UTF-8?Q?Re:_GUI-Update_=c3=bcber_Swing-EDT?= Date: Fri, 15 Jul 2016 22:43:07 +0200 Organization: news.netcologne.de Distribution: world Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Fri, 15 Jul 2016 20:43:08 +0000 (UTC) Injection-Info: newsreader4.netcologne.de; posting-host="xdsl-84-44-179-215.netcologne.de:84.44.179.215"; logging-data="31076"; mail-complaints-to="abuse@netcologne.de" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.24) Gecko/20100411 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 In-Reply-To: Xref: csiph.com de.comp.lang.java:12994 Responding to Christian H. Kuhn: > 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. Natürlich soll QChessClock nichts von Swing wissen. Aber irgendwo musst Du für den Zugriff auf die GUI halt in den EDT. Und das wäre bei Deinem aktuellen Codestand halt in den Implementierungen der #update()-Methoden, wo auf die GUI-Komponenten zugegriffen wird. > QChessClockJavaAVTest greift nur an einer Stelle anders als per > notifyObservers() direkt schreibend auf die GUI zu. Was ist mit #doClick()? Ich bin äußerst zuversichtlich, dass das auch in den EDT gehört - sonst hätte ich ja auch keine "lost clicks" gesehen. :) Im von Dir angesprochenen JW-Artikel wird das auch so gemacht. Und auch, wenn die das nicht so machen: #getChildIndexed() & Co. gehören auch dahin. Einfach alles, was irgendwie auf GUI-Komponenten zugreift und/oder GUI-Zustandsänderungen triggert. > 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 ist eine sehr eigenwillige Beschreibung, und allerspätestens für Felder grundfalsch. :) Du hast Dir mit der Schachuhr ein Projekt ausgesucht, wo Du Concurrency verstehen musst. Mit wolkigen Metaphern kommst Du nicht weit, die Thematik ist eher wenig intuitiv. Schau vielleicht mal in die entsprechende Lesson im Oracle-Tutorial: https://docs.oracle.com/javase/tutorial/essential/concurrency/index.html Viele Grüße, Patrick