Expertenfrage zu Refresh nach hinzufuegen von Componeten?

[jago]

Hi,

ich habe ein JPanel dem ich Componenten hinzufuege. Das hab ich schon zigmal gemacht nur will er diesmal nicht die Groesse des JPanel nach dem hinzufuegen anpassen obwohl ich folgendes aufrufe:

panel.invalidate();
panel.validate();
panel.repaint();

Lustigerweise reicht es aus das JFrame zu minimieren und wieder in den Vordergrund holen (eigentlich gibts dann nur ein repaint, oder?) um die von mir gewuenschte Groessenaenderung durchzufuehren.


Irgendwie sind parents von panel zu faul der Aenderung von meinem JPanel zu folgen und die Groesse von JPanel anzupassen. Nach vielem experimentieren habe ich festgestellt, dass ein:

panel.getParent().getParent().invalidate();
panel.getParent().getParent().validate();
panel.getParent().getParent().repaint();

den gewuenschten Effekt bringt und die Groesse von JPanel anpasst und ich nun alle hinzugefuegten Componenten sehe.


Kann mir jemand erklaeren was da passiert? Blockiert der weiter oben liegende Parent-Container dies oder was laeuft falsch wenn ich den Refresh-Vorgang direkt auf das panel ausfuehren will? Irgendwo wird vielleicht die Information dass neue Componenten hinzugefuegt wurden nicht weitergeleitet oder ignoriert?

Ich wuerde leiber gerne das Problem verstehen als zu diesem Hack zu greifen zumal ich nicht immer weiss der wievielte parent es ist und aus vielen anderen Gruenden.

Wie geht man einem solchen Problem nach? Wie detektieren die parents weiter oben normalerweise ob sie gelayouted werden muessen oder nicht?

 

[Marco13]

Schau auch mal hier http://www.java-forum.org/de/viewtopic.php?p=363146#363146

Normalerweise sollte zumindest ein revalidate() alles notwendige erledigen, aber .... Niemand weiß, welche Strukturen du verwendest, WIE da WAS ineinander geschachtelt ist, welche LayoutManager du verwendest, und was du mit den PreferredSizes o.ä. machst, deswegen ist es schwierig, das was genaueres dazu zu sagen....

 

[Guest]

Schau auch mal hier http://www.java-forum.org/de/viewtopic.php?p=363146#363146

Normalerweise sollte zumindest ein revalidate() alles notwendige erledigen, aber .... Niemand weiß, welche Strukturen du verwendest, WIE da WAS ineinander geschachtelt ist, welche LayoutManager du verwendest, und was du mit den PreferredSizes o.ä. machst, deswegen ist es schwierig, das was genaueres dazu zu sagen....

Danke ich lese es gleich. nochmal zu den PreferredSizes. Ich habe schon gecheckt ob die sich von meinem JPanel aendert wenn ich Components hinzufuege. Das tut sie. Die PreferredSize wird groesser oder kleiner, abhaengig was ich nach einem removeAll() hinzufuege.



revalidate() scheint es uebrigens zu fixen - danke! Weisst du jetzt woran es lag. Normalerweise hab ich immer invalidate und dann validate aufgerufen und gut wars. Ich dachte immer revalidate wuerde intern genau das tun.



Selsam ist schon, dass wenn ich das Fenster minimiere und dann in den Vordergrund hole das Layout auch wieder gefixt wird. Wie kann man das erklaeren?


Gruss,
jago

 

[Marco13]

Nochmal: Ich weiß nicht, WAS an deinem Layout nicht gestimmt hat, und woran das (bei dir) gelegen haben könnte. Aber... ganz grob und sinngemäß: validate() bezieht sich nur auf die Component, auf der es aufgerufen wurde, und revalidate() geht sozusagen die Hierarchie nach oben bis zum Frame, und validatet ALLES (macht also etwas, was auch beim Minimieren und Wiederherstellen gemacht wird)

 

[jago]

Nochmal: Ich weiß nicht, WAS an deinem Layout nicht gestimmt hat, und woran das (bei dir) gelegen haben könnte. Aber... ganz grob und sinngemäß: validate() bezieht sich nur auf die Component, auf der es aufgerufen wurde, und revalidate() geht sozusagen die Hierarchie nach oben bis zum Frame, und validatet ALLES (macht also etwas, was auch beim Minimieren und Wiederherstellen gemacht wird)

Ich hab schon das Javadoc von revalidate() gelesen und verstanden - sozusagen eine brute-force methode. Aber du hast recht, du kannst nicht wissen warum ein invalidate() gefolgt von einem repaint() nicht ausreicht.

http://www.java-forum.org/de/viewtopic.php?p=363146#363146 finde ich uebrigens teilweise Fehler und Unklarheiten. Javadocs scheinen besser. Habe schon von revalidate gehoert aber wieder vergessen was die so macht und mich auch nicht mehr erinnert.

Danke!

 

[Beni]

http://www.java-forum.org/de/viewtopic.php?p=363146#363146 finde ich uebrigens teilweise Fehler und Unklarheiten. Javadocs scheinen besser. Habe schon von revalidate gehoert aber wieder vergessen was die so macht und mich auch nicht mehr erinnert.

Verbesserungen sind immer erwünscht, was für Fehler und Unklarheiten findest du?

 

[Guest]

http://www.java-forum.org/de/viewtopic.php?p=363146#363146 finde ich uebrigens teilweise Fehler und Unklarheiten. Javadocs scheinen besser. Habe schon von revalidate gehoert aber wieder vergessen was die so macht und mich auch nicht mehr erinnert.

Verbesserungen sind immer erwünscht, was für Fehler und Unklarheiten findest du?

Ich finde jetzt den Fehler nicht. Aber bzgl. Unklarheiten finde ich die Art wie es geschrieben ist teilweise seltsam.

Bsp.: revalidate

Aufgabe: Zuerst invalidate aufrufen, und dafür sorgen, dass zu einem späteren Zeitpunkt validate aufgerufen wird.

Aufgabe: Zuerst invalidate aufrufen - klingt fuer mich so als waere es eine Anweisung an den Programmierer der revalidate nutzen will. Klar nachdem man sich an diesen Stil gewoehnt hat ist es kein Problem mehr. Allerdings kann man es auch einfacher ausdruecken:

Intera: revalidate ruft zunaechst invalidate auf und sorgt dafuer, dass zu einem späteren Zeitpunkt validate aufgerufen wird.


Versteh mich nicht falsch...ich finde es sehr gut das es so eine Liste gibt!

 

[Beni]

Hmok, das kann ich bei Gelegenheit mal anpassen. Ich habe mir damals nicht soviele Gedanken gemacht :wink:

 

[André Uhres]

Validierung mit Swing

Hier ist eine etwas ausführlichere Beschreibung des Swing Validierungsmechanismus.

Das Herzstück des Swing Mal- und Validierungsmechanismus ist der RepaintManager.
Er ist dafür verantwortlich, daß die Mal- und Validierungsanträge zur AWT Event Queue geschickt werden, wo sie abgefertigt werden. Er macht dies, indem er die repaint() und revalidate() Anträge abfängt, wenn möglich irdendwelche Anträge zu einem einzigen zusammenfasst, sie in ein Runnable Objekt packt und an invokeLater weitergibt.

Ein revalidate() Antrag wird jedesmal erzeugt, wenn eine Komponente neu ausgelegt werden muss. Wenn ein Antrag von einer gewissen Komponente ankommt, muss man herausfinden können, ob das Auslegen dieser Komponente noch andere berührt. Die JComponent Methode "isValidateRoot()" gibt für die meisten Komponenten "false" zurück. Grundsätzlich ist der Aufruf dieser Methode gleichbedeutend mit der Frage: wenn ich deinen Inhalt neu auslege, kannst du mir garantieren, daß keiner deiner Vorfahren und Geschwister ungünstig beeinflusst wird (also neu ausgelegt werden muss)? Nur JRootPane, JScrollPane, und JTextField geben true als default Wert zurück. Das sind die einzigen Swing Komponenten, deren Inhalt in jeder Situation erfolgreich ausgelegt werden kann, ohne irgendwelche Vorfahren oder Geschwister zu berühren. Egal wie gross wir irgendwas innerhalb eines JRootPane, JScrollPane oder JTextField machen, wird sich ihre Grösse oder Position nicht ändern (ausser wenn ein Einfluss von ausserhalb mitspielt, also ein Geschwister oder Vorfahr).

Eine Komponente oder ihr Vorfahr wird gewöhnlich neu validiert, wenn der Wert einer Eigenschaft ändert, welche die Grösse, die Position oder das interne Layout dieser Komponente beeinflusst. Indem wir "isValidateRoot()" rekursiv auf dem Vorfahr einer Swing Komponente aufrufen, bis wir "true" erhalten, werden wir den nächsten Vorfahr dieser Komponente ermitteln, welcher uns garantiert, daß seine Validierung keinen seiner Geschwister oder Vorfahren ungünstig beeinflusst. Der RepaintManager stützt sich auf diese Methode um die Validierungsanträge abzufertigen.

Anmerkung: "Geschwister" sind Komponenten innerhalb desselben Containers. "Vorfahren" sind Container, die in derselben Containerhierarchie höher liegen.

Der RepaintManager führt einen Vector von Komponenten, die validiert werden müssen. Jedesmal wenn ein "revalidate" Antrag ankommt, wird die Auslöserkomponente an die addInvalidComponent() Methode geschickt und ihre "validateRoot" Eigenschaft wird mittels "isValidateRoot()" überprüft. Das geschieht rekurisv auf dem Vorfahr der Komponente, bis isValidateRoot() "true" zurückgibt. Die erreichte Komponente, falls eine da ist, wird auf Sichbarkeit überprüft. Wenn irgendeiner der Vorfahrcontainer nicht sichtbar ist, dann besteht kein Grund, zu validieren. Der RepaintManager prüft dann seinen Vector der nicht validen Komponenten und wenn die Rootkomponente noch nicht drin ist, wird sie hinzugefügt. Nachdem sie erfolgreich hinzugefügt wurde, übergibt der RepaintManager die Komponente an die Methode queueComponentWorkRequest() der Klasse SystemEventQueueUtilities. Diese Methode prüft ob schon ein dem Root entsprechender ComponentWorkRequest in der "work requests table" drin ist. Wenn schon einer da ist, holen wir uns lediglich die Referenz darauf. Dann synchronisieren wir den Zugang zu diesem ComponentWorkRequest, setzen ihn in die "work requests table", wenn es ein neuer ist, und prüfen, ob er schon ansteht (d.h. er wurde zur AWT Event Queue hinzugefügt). Wenn er noch nicht ansteht, schicken wir ihn an SwingUtilities.invokeLater(). Er wird dann als "anstehend" gekennzeichnet und wir verlassen den synchronisierten Abschnitt. Wenn er schliesslich auf dem "event-dispatching thread" ausgeführt wird, teilt er dem RepaintManager mit, er soll validateInvalidComponents() ausführen, gefolgt von paintDirtyRegions().
Die Methode validateInvalidComponents() prüft grundsätzlich den Vector der Komponenten, die validiert werden müssen, und ruft validate() auf jedem davon auf.

Hier ist noch ein Artikel, der speziell die Swing Malmechanismen erklärt: Malen in AWT und Swing