J'aurai 2 questions sur les JTextField et les JTextArea.
 
D'abord j'aimerai placer mon JTextField n'importe ou sur mon panneau sans utiliser de layout (j'y comprend rien et avec mon application ca correspond pas trop) On m'a dit d'essayer setBounds mais ca ne marche pas, pk ?
 

 
Et ensuite j'ai une fenetre et j'aimerai afficher du texte dedans donc je passe par un JTextArea mais rien ne s'affiche, vous savez pk ? Sachant que je ne les ai jamais manié donc j'ai du oublier des parametres...
 

 
 
Merci pour votre aide

faudrait peut-être ajouter tes composants à qqch non ?
et ta classe Info, elle sous-classerait pas une autre classe par hasard ?

Si :
 
public class Info extends JFrame
 
Et ajouter mes composants a quoi ? désolé je debute la dedans

ben les ajouter à Info
sinon, comment pourraient ils s afficher ?

 
Cool j'ai reussis :
getContentPane().add(sortie);
Et voila mon JTextArea s'affiche !!
 
Merci bco  
 
Une idée pour placer le JTextField ou je veux ?

ben de rien
ça marche pas avec setBounds ?  
je ne peux que te conseiller d'utiliser des layout, le placement absolu des composant ça semble plaisant et facile, mais tu vas vite en voir les limites : appli qui n'aura pas le même aspect selon les platesformes, textes tronqués, quand on redimensionne rien ne se passe au niveau du layout etc

Ben avec le code mis plus haut (avec setBounds) rien ne s'affiche, je ne vois pas mon JTextField.
J'imagine que le placement absolu est bof mais je n'ai qu'un seul JTextField a mettre sur tout mon programme et c sur une grande fenetre donc c bcp plus pratique (je ne vois pas comment faire pour le place sinon).

question bête : tu as fait un getContentPane().add(nb);

 
 
 
 
Nan...  
Bon ben ca marche alors, merci bcp !!
 
Merci bcp en tout cas

de rien
bonne continuation en Java

 
Merci

Le conseil gratuit du jour : ne jamais sous-classer JFrame.

 
oui, je sais le tutorial swing tout ça ... mais non, c'est nul de sous-classer les classes swing.

 
 
ça m'intéresse ce que tu dis là, peux-tu nous en dire davantage ?
merci
 

Une sous-classe de JFrame, ça reste une JFrame.
 
Une JFrame ça peut s'utiliser en lui faisant un beau setContentPane par exemple. Si ta sous-classe avait mis du bordel dans le content-pane, il s'est fait virer avec le content-pane.
 
En gros, quand tu sous-classe, tu n'as pas le droit de casser ce qui marchait dans la super-classe. Tu peux par exemple imaginer mettre des roues à un JFrame, ça restera un JFrame et l'aspect "avec des roue" n'influe pas sur l'aspect JFrame, tu peux donc imaginer une sous-classe de JFrame qui serait JFrameAvecDesRoues.
 
Pareil pour le reste de swing, sauf cas très rare, on ne sousclasse pas, il y a des setBidule et getMachin et les interfaces (qui elles sont prévues pour être sousclassées) qui vont avec dans tous les sens pour faire à peu près tout.

donc ça diffère de AWT où on sous-classe Frame ?

J'ai pas étudié AWT. Mais sousclasser Frame me semble une mauvaise idée de manière générale.

bof je vois pas en quoi avoir un Frame membre de la classe est plus propr
Pour JFrame, y a des bouquins où ton conseil est repris ?

Tous les bouquins traitant de la POO ?

Loizo > vous avez pas fait de swing du tout ??? moi j'en ai bouffé en 1er année
 
nraynaud > si ta un article qui parle de ça ca m'intéresse

 
En 2eme année on a fait du java et donc un peu de swing mais pas en 1ere année.
Et les JtextField et tout on a vu ca vaguement donc bon je galere un peu...

j'ai toujours sous-classé Frame en AWT, mes collègues aussi
Maintenant, Swing je connais pas

 
vous faites koi comme langage ? Cpp ?

L'informatique est incapable de mener un projet à son terme dans les conditions prévues depuis toujours.  
"depuis toujours" n'est pas un argument.

keske tu racontes ?
je donnais pas ça comme argument, je disais juste que ça me suprenait. Si je veux faire une classe qui est ue fenêtre, je vois pas pourquoi je sous classerai pas Frame, sémantiquement ça se tient tout à fait

Parce que "Frame" ne représente pas "une fenêtre", mais une fenêtre vide, avec tout un tas de caractéristiques que je suis convaincu que tu ne vas pas conserver dans ta sous-classe, vu que sousclasser ne sert pas a faire ce que tu en fais ?
 
Ensuite parce que pour sousclasser une classe concrète, il faut avoir une sacré bonne raison (que tu serais bien en peine de me fournir).
 
Enfin, et c'est là mon argument le plus fort, si je dis quelquechose, c'est *vrai* car je suis le chemin de la vérité.
Sur ce, je vais prendre mes pilules, je crois que ça dévie.
 
 
edit : la raison profonde tient à la relation "is A" de Meyer, mais j'ai vraiment la flemme de l'expliquer, et c'est dans tous les bouquins de POO.
 
edit2 : par contre, j'aimerais savoir pourquoi les tutoriaux swing sont aussi nazes de ce point de vue, à se demander qui les a écrits.

 
ton argumentation est biaisée
biensur, l'héritage, c'est lié à la relation "is A", mais c'est aussi un moyen de spécialiser une classe
 
ceci dit, je suis loin d'être un spécialiste de la POO, et je veux bien apprendre
J'aimerais l'avis d'autres Javaistes confirmés

 
Nan en 2eme année on fait du java c'est tout (enfin esentiellement quoi)
Pas vous ?

 
ben on fait java et C premiere & deuxieme année

 
C on en a fait un peu l'année derniere et un peu cette année avec les socket mais sans plus quoi. Mon projet j'avais le choix entre C++ et Java mais vu que le peu de C++ que j'ai vu j'ai trouvé ca horrible (syntaxe super compliqué avec les socket, tjs 50 parametres c lourd) donc j'ai pris java.

 
uhm    
 
faut croire qu'on fait pas du tout la meme chose  

 
En gros ca doit rester la meme chose quand meme