Ici il ne s'agit pas du fonctionnement de la méthode repaint() mais d'une illustration des demandes de peintures déclenchées par le système d'exploitation. Quand une opération de peinture est déclenchée par le système, le système demande au composant d'afficher son contenu, généralement pour une des raisons suivantes:

     * Le composant est affiché pour la première fois visiblement à l'écran.
     * Le composant a été redimensionné.
     * Le composant a été endommagé et doit être réparé.

Pour permettre aux applications de déclencher eux-mêmes une opération de peinture, l'AWT fournit les méthodes java.awt.Component suivantes pour que les programmes puissent demander un processus de peinture asynchrone:

    public void repaint()
    public void repaint(long tm)
    public void repaint(int x, int y, int width, int height)
    public void repaint(long tm, int x, int y, int width, int height)

Cordialement,
André

Bonjour COUNDOULIBZO, je n'est pas "MS SQL". Peux-tu exporter les données du "MS SQL" vers des fichiers textes s.t.p.? Je voudrais les importer dans "MS Access". André

Bien fait Julien!
Petite remarque: le redimensionnement ne suit pas les standards établis; par exemple, la forme du pointeur de la souris ne s'adapte pas de la même façon, on ne peut pas modifier la largeur sans que la hauteur bouge aussi, etc.
Bien à toi,
André

Utilisez la nouvelle classe StringBuilder dans la mesure du possible.

    * StringBuilder a été introduit dans le JDK 1.5 pour remplacer StringBuffer dans l'usage "single-threaded".

    * StringBuffer est conçu pour être "thread-safe" et toutes les méthodes publiques dans StringBuffer sont synchronisées. StringBuilder ne gère pas la question de sécurité des threads et aucune de ses méthodes est synchronisée.

    * StringBuilder a de meilleures performances que StringBuffer dans la plupart des cas.



La classe parente de StringBuilder et de StringBuffer s'appelle "AbstractStringBuilder" et contient un attribut de type char[] de taille par défaut 16, qui est utilisé pour le stockage des caractères. C'est donc un tableau qui n'est pas dynamique et il est important de spécifier la taille des StringBuilder si on la connait d'avance (comparer avec le paragraphe "Initialiser la taille des ArrayList").

Salutations,
André

Merci Kimjoa,

ça fonctionne bien maintenant, il n'y a plus d'exception! Le répertoire est déplacé et l'explorateur est actualisé (avec la première version, le répertoire était également déplacé, mais l'explorateur n'était pas actualisé à cause de l'exception).

Salutations,
André

J'ai quand même reçu une exception lors du déplacement d'un répertoire:
c:\Intel\Label
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
        at tree5.TreeSystemModel.refreshFilesDirectories(TreeSystemModel.java:66)
        at tree5.TreeSystemController$OnPaste.doPaste(TreeSystemController.java:245)
        at tree5.TreeSystemController$OnPaste.actionPerformed(TreeSystemController.java:216)

L'exception vise l'instruction suivante:
parent.removeAllChildren();
(dans la méthode refreshFilesDirectories du TreeSystemModel)

A première vue, cela fonctionne très bien chez mois. Il y a peut-être un soucis pour le "Voisinage réseau" qui ne montre que le raccourci vers la destination et non pas la destination elle-même. Mais ça c'est un détail, à mon avis. Bon travail! Au niveau code je ne peux rien dire (je ne l'ai pas regardé).

http://www.mediafire.com/?jkxtojw2no4

La méthode "repaint" avec les arguments qui définissent le rectangle à redessiner existe dans la classe JComponent. Il n'y a donc rien à redéfinir.
Effectvement, dans la boucle "for" on appelle des "repaint" multiples sur le "Panneau". Quand des repaint() multiples sont appelé sur un composant avant que le premier appel ne soit traité, le Repaintmanager de Swing peut réunir les appels multiples en un seul appel. Donc cela ne risque pas de faire "beaucoup". Quand des appels multiples sont ainsi réunis, le rectangle "clip" résultant est égal à la réunion des rectangles qui sont contenus dans les appels réunis.

Voici quelques réflections au sujet de l'utlisation des threads dans ton exemple. Premièrement, une application Swing doit toujours démarrer sur le "EventDispatchThread" en utilisant la méthode "invokeLater":
[code]
public static void main(String[] args) {
    Runnable gui = new Runnable() {
        public void run() {
            int largeur = 200;
            int hauteur = 200;
            new Fenetre(largeur, hauteur);
        }
    };
    SwingUtilities.invokeLater(gui);
}
[/code]
Ensuite, pour réaliser l'animation, on utilise un thread d'arrière plan. Par exemple:
[code]
new Thread(new Runnable() {
    public void run() {
        go();
    }
}).start();
[/code]
Dans le thread d'arrière plan, les modifications de l'interface graphique doivent de nouveau être envoyées vers le "EventDispatchThread". Pour ce faire, on utilise généralement la méthode "invokeLater" (ou "invokeAndWait"). Cependant, il existe un petit nombre de méthodes Swing qui font ça automatiquement. On dit également que ces méthodes sont "thread safe". La méthode "repaint" en est un exemple. Cependant, dans la méthode "go", c'est préférable de déplacer le "repaint" vers l'intérieur de la boucle "for" en définissant exactement le rectangle à redessiner:
[code]
    //On redessine notre Carre
    int OFFSET = 1;
    pan.repaint(c.getPosX() - OFFSET, c.getPosY() - OFFSET,
            c.getLargeur() + OFFSET * 2, c.getHauteur() + OFFSET * 2);

} // fin du for
[/code]
Ceci nous permet d'optimiser la méthode "paintComponent" en ne redessinant que ce qui est nécessaire, c.à d. ce qui chevauche le rectangle "clip". Par exemple, pour dessiner le fond blanc au début de la méthode "paintComponent":
[code]
Rectangle r = g.getClipBounds();
g.fillRect(r.x, r.y, r.width, r.height);
[/code]