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...).

VB 11 fois plus lent que delphi... ca laisse songeur en effet, mais quand on voit le code, on n'a plus aucun doute :p

Hormis quelques cas d'utilisation particuliers, VB n'a pas a rougir face au C (je ne parle pas du Delphi que je ne connais pas). VB une fois compilé (et non exécuté en mode debug !), et le code un tant soit peu optimisé (ne pas déclarer les variables dans ton code, c'est vraiment très très limite ! faire plusieurs Resume Next qui servent à rien, faire un doEvents).

Ca ne sert à rien de tester la rapidité des différents langages si tu ne les connais pas à fond...

D'ailleurs, ton commentaire m'a bien fait rire :
DoEvents 'sécurité pour pas faire planter votre pc (tu m'étonne que c'est lent toi après !)

LOL

Conclusion : rien ne vaut le langage PCPT++

DarK Sidious

Bah de rien, il est là pour cà, content de voir que cette source est toujours utile :p