validate() ? revalidate() ? rePaint() ?

Bonjour,

en travaillant aujourd'hui, je me rend compte de ca sur ma JFrame qui contient un ScrollPane :

-> validate(a pour effet de mettre par défault le curseur de ma ScrollBar en bas, et celle-ci n'est visible qu'une fois que je click dans le scrollPane)

-> revalidate a pour effer de faire ce que je veux (a savoir afficher directment ma scrollBar et correctement avec le curseur en haut).

-> rePaint() lui ... grossomodo comme validate.

ma question : POURQUOI ?

C'est quoi trés concrètement la différence des 3 ? parce que certes la doc est la mais pas non plus limpide quoi :)


Merci

Une IHM Swing est formée de composants imbriqués les uns dans les autres. À leur création, ils n'ont pas de position ni de dimensions définies et ils sont donc marqués comme (ayant une mise en page) invalide. Valider un composant est ainsi l’opération servant à déterminer sa position et ses dimensions.

La validation des composants élémentaires est généralement triviale et l'essentiel du travail de validation se situe dans les conteneurs à travers leur LayoutManager (note en passant : un JComponent de Swing est un Container AWT qui est lui-même un Component AWT). Ce système de validation fonctionne à travers plusieurs méthodes :

• Component.isValid indique si un composant est valide ou non.
  
• Component.invalidate marque un composant (et tous ses ancêtres) comme invalides. Son appel ne quasiment coûte rien (c'est juste un marquage).
  
• Component.validate demande à un composant de recalculer ses dimensions et donc, dans le cas des conteneurs, de refaire sa mise en page. C'est une opération potentiellement « coûteuse ».
  
• JComponent.revalidate (introduite par Swing) est une combinaison des deux précédentes qui appelle Component.invalidate et enregistre le composant et tous ses ancêtres dans un cache au niveau de l'ancêtre terminal (le parent qui n'a pas lui-même de parent, c'est à dire la fenêtre). Lorsque tous les événements de l'EDT auront été traités, ce cache sera sollicité pour pouvoir appeler Component.validate sur les composants enregistrés. De cette manière on évite d'appeler plusieurs fois Component.validate et pas forcément dans le bon ordre.
  
• Window.pack qui exécute récursivement Component.validate sur toute une IHM. C'est typiquement la méthode qu'on appelle avant d'appeler setVisible(true) sur une IHM nouvellement créée (l'alternative est de fixer soi-même une taille).
  
• Component.repaint, quant à elle, n'a rien à voir avec tout ça. Elle sert à marquer un composant comme étant « à redessiner » et, s'il n'est pas opaque, à marquer son parent comme « dirty » (c'est à dire « à redessiner », mais en sachant qu'il n'a pas changé lui-même et qu'une image bufferisée peut être utilisée pour le restaurer).
  

Note : Component.setVisible provoque aussi une validation dans le cas où le composant est rendu visible pour la première fois (un composant a aussi un état displayable en plus de son état valid).

Voilà pour le détail. En pratique et dans la majorité des cas, les méthodes de validation n'ont pas besoin d'être utilisées directement. Il faut juste penser à appeler Window.pack pour les nouvelles fenêtres (si on ne veut pas fixer de taille nous-même) et d'appeler JComponent.revalidate sur les conteneurs déjà visibles dont on modifie après-coup le contenu (c. à d. ajout ou retrait d'enfants). C'est tout.