Très sympa ces petits boutons, je les réutiliserai peut-être dans l'un de mes projets.

Le code est clair et bien fait.

Bon boulot.

C'est joli, fluide, mais un peu trop rapide à mon goût sur ma machine (on a quasiment pas le temps de voir les bulles), tu devrais rajouter un petit paramétrage du temps d'attente entre 2 affichages pour régler la vitesse de défilement des bulles.

Sinon, j'ai une exception qui se déclenche, je te laisse la stacktrace complète afin que tu puisse debugguer (sûrement un problème de synchronisation entre le remove et le paint dans ton thread) :

Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: No such child: 31
at java.awt.Container.getComponent(Unknown Source)
at javax.swing.JComponent.rectangleIsObscured(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintToOffscreen(Unknown Source)
at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(Unknown Source)
at javax.swing.RepaintManager$PaintManager.paint(Unknown Source)
at javax.swing.RepaintManager.paint(Unknown Source)
at javax.swing.JComponent._paintImmediately(Unknown Source)
at javax.swing.JComponent.paintImmediately(Unknown Source)
at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
at javax.swing.RepaintManager.seqPaintDirtyRegions(Unknown Source)
at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)


C'est une jolie utilisation de ma source de tracé de bouton avec effet glass ;)

Je ne sais pas comment tu t'y prends, mais ca marche très bien chez moi :
JTextField txtFilterInteger = new JTextField();
txtFilterInteger.setDocument(new IntegerFilter());
txtFilterInteger.setText("12"); // affiche 12

JTextField txtFilterInteger = new JTextField();
txtFilterInteger.setDocument(new IntegerFilter());
txtFilterInteger.setText("aa"); // n'affiche rien

C'est pourtant guère sorcier, en reprenant mon code de test...

_txtFilterInteger = new JTextField();
_txtFilterInteger.setDocument(new IntegerFilter());

Vérifie que tu n'as pas une exception qui est déclenché : est-ce que le fichier est correct ? Est-ce que les espaces dans le nom du fichier ne posent pas problème ?

De toute façon, ta façon de faire n'est pas la bonne : ca ne marchera que tant que le fichier existera, et qu'il sera placé sur le bureau du user "Administrateur" => gros risque qu'un beau jour le fichier soit supprimé ou déplacé.

Privilégie une image contenue dans le jar de ton application : beaucoup plus sûr !

Je trouve pas grand intérêt à ta source : il ne s'agit que de l'utilisation de la méthode add du Calendar. Du coup, si tu enlève tout le code de ton interface graphique, ton code se résume à ceci :

int yy1=Integer.parseInt(y1.getText()),
           mm1=Integer.parseInt(m1.getText()),
           dd1=Integer.parseInt(d1.getText()),
           nbj1=Integer.parseInt(nbj.getText());
        
       String dy= y1.getText()+"/"+ m1.getText()+"/"+  d1.getText();

       // Date s1=new Date(yy1,mm1,dd1);
       Date s1=new Date(dy);
     GregorianCalendar calendar = new java.util.GregorianCalendar();
    
     calendar.setTime(s1);
     calendar.add(Calendar.DATE, nbj1);

     Date nouveau=calendar.getTime();


DateFormat dateFormat = new SimpleDateFormat("dd/MM/yy");
String result=dateFormat.format(nouveau);
ndate.setText(result);

Bref, rien de bien transcendant. Tu devrais plutôt déposer ton code dans les snippets.
Ca peut être utile à ceux qui débutent à la limite (j'ai répondu dernièrement à un membre qui se posait cette question), mais c'est quand même très limité car déjà documenté dans la javaDoc.

666merlin : à part passer par une applet signée (qui aurait donc accès au presse-papier), ta demande me semble guère réalisable : il faut du code s'éxécutant niveau client, donc oublie le PHP. Le javascript ne te permettra pas de faire cà, à moins de passer par un ocx qui ne sera pas portable. Java te le permet, mais au coût d'une applet signé (lourd à charger, et oblige l'utilisateur à utiliser un certificat pour utiliser l'applet). Après faut voir du côté de flash ou de silverlight s'ils proposent une solution à cà.

Il est vrai que si à une époque, je commentais trop mes sources (voir mes premières sources), maintenant je les commente au strict minimum.

Bien entendu que tu peux reprendre mon code pour faire un autre projet, il est là pour cà. Par contre, si en retour tu peux poster le projet que tu as fait en t'inspirant de mon code, ce serait très sympa pour toute la communauté Codes-Sources (tu n'es pas obligé).

"qui n'est pas de moi" : tu aurais au moins pu citer l'auteur original de cette source... Ne serait-ce que par respect de son travail...

Je n'utilise pas VB.NET, et je n'ai jamais utilisé VB.NET 2008, je ne peux donc pas savoir en comparant VB.NET 2008 à VB6, mais 30 fois supérieur, ca me semble énorme... Déjà un facteur 2 est énorme pour un algorithme identique avec un code optimisé pour les deux langages comparés...

Cela m'étonnerai fortement que VB.NET 2008 soit plus rapide que du C++ : C++ est un langage très vieux, et surtout, pensé pour les performances, tout comme le C. Il est compilé en natif, ce qui veut dire qu'il sais parlé directement au système, contrairement à .NET qui lui est interprété, et passe donc par une surcouche pour accéder au système. Cela a un avantage : le code peut être optimisé en temps réel, avec la mise en cache d'instructions souvent exécutées par exemple, ce qui n'est pas possible en compilé natif (moteur JIT). Par contre, il a l'énorme inconvénient d'être interprêté, et donc, le pc doit d'abord traduire les instructions de code avant de pouvoir les exécuter, ce qui lui donne du travail supplémentaire, contrairement à C++. .NET est censé apporter la portabilité au programme, mais malgré les quelques projet à ce propos, on peut dire que c'est un échec !

Je parle bien de C++ et non de Visual C++ (et encore moins de C++.NET !!!) qui n'est qu'un outil, et n'a rien à voir avec le programme final !

Perso, j'ai fait mon choix : au lieu d'utiliser VB.NET, qui aurait été logique après l'utilisation de VB6, je me suis tourné vers JAVA qui est un langage bien plus pérenne que ceux made by Microsoft qui changent toute les 3 versions (de là à dire que .NET 3 serait la dernière version avant une nouvelle révolution... en tout cas ca me ferais bien marré de voir tout ce qui ne jure que par C# ou VB.NET, et crachent sur JAVA), avec tout ce que ca engendre (incompatibilités et recodage complet des applications...).