Bonjour... Croyez bien que je regrette de demander de l'aide mais là je ne comprends pas mon erreur... en fait j'utilise le GridBagLayout et j'essaye d'avoir une grille avec 7 cases de différentes couleurs dnas l'image qui suit il y a à gauche ce que je devrais obteir en théorie et à droite ce que j'obtiens...
http://img98.imageshack.us/img98/7843/java1rp.png
Si quelqu'un peut m'aider.
Merci
for(cpt = 0; cpt<nbTot;cpt++){
tabCentres[cpt] = newJPanel();
gbc = paneAff(tabCentres[cpt],cT.tabVal[cpt]);
paneAjout.add(tabCentres[cpt], gbc); // c'est peut être le nom de la variable paneCentre }
Moi j'ai déjà utilisé des Box et des BoxLayout et c'était beaucoup plus simple (d'apres mon prof) que le GridBagLayout.
Ensuite (toujours d'apres ce que m'a dit mon prof) ton code est horrible...
extends JFrame <- pas bien !
Car si tu veux hériter d'une autre classe, tu peux pas.
Ensuite tapez toutes tes composants en global, mauvaise idée aussi. Faut le moins de variables globales !
Si tu as besoin d'une variable, tu l'a passes en paramètres à la méthode qui en a besoin.
Pour le BoxLayout, voici un exemple :
(c'est pour un project que je dois rendre) :
Je sais parfaitement que on code est horrible, c'est un brouillon, la version finale sera bien différente.
En ce qui concerne les variables globales, tant que je ne connais pas tous les endroits où elles seront utilisées je les laisse en global. Ensuite je verrai où les remettre. Mais je n'aime pas me soucier de la lisibilité du code tant que je 'narrive pas à la version finale.
Enfin j'ai besoin du GridBagLayout vu ce qu'on me demande d'afficher. Vu ce que j'ai pu lire sur ls autres gestionnaires, ça n'offre pas la liberté dont j'ai besoin. Hélas....
Ceci dit j'ai résoulu le pb depuis que j'ai posté ce message (car même si j'en ai pas l'air parfois je réfléchis :P)
extends JFrame <- pas bien !
Car si tu veux hériter d'une autre classe, tu peux pas.
Ensuite tapez toutes tes composants en global, mauvaise idée aussi. Faut le moins de variables globales !
Si tu as besoin d'une variable, tu l'a passes en paramètres à la méthode qui en a besoin.
Alors la je suis pas d'accord faire un extends des classe swing n'a rien de crade, et mettre les composants en variable de classe n'a rien de faux.
Meme si l'heritage multiple n'est pas possible en JAVA, c'est beaucoup plus propre de dériver des classe swing afin de pouvoir surcharger la methode paintComponent() et autre fioritures de ce genre. De plus on peut se passez de l'heritage multiple pour les les classe type UI car en général elle extends que l'un des composant SWING (sinon on peut se debrouiller avec les interfaces)
Avoir les variables des JComposants n'a rien de lourd et est même beaucoup plus propre car au moins tu sais de quoi est composé ta fenetre.
étendre les classe swing est très propre je trouve par contre implémenter les listener directement dans la classe frame l'est beaucoup moins, les class interne sont beaucoup plus propre.
enfin bon ici c'est surtout une question de philosophie. De toute facon les prof ne sont jamais d'accord entre eux. Et les informatitiens non plus. D'ailleurs il existe un nom pour ce genre de discussion
je parlais des dispute en générale entre programmeur qui souvent ne s'appuye pas sur des arguments valable parce que les deux cas sont tout aussi bien mais ca dépend des préférence de chacun.
sinon
Citation : Pas de titre
Avoir les variables des JComposants n'a rien de lourd et est même beaucoup plus propre car au moins tu sais de quoi est composé ta fenetre.
je suis tout a fait d'accord que de mettre les objet JCompenents en variable d'instance est beaucoup plus propre mais rien n'empeche de le faire même si on étend pas la classe frame. donc cet argument est moyen.
Par contre un très bon argument est:
Citation : Pas de titre
afin de pouvoir surcharger la methode paintComponent()
ps: donner son avis sans arguments (comme je le fait), c'est ce rapprocher du troll
oh et puis merde on s'en fou de toute facon le code était dégeu
L'avantage du WindowsListener c'est que tu controle ton appli lors de la fermeture de la fenêtre ce que le setDefaultCloseOperation ne te permet pas (par exemple en fermant une fenetre de rendu tu peux terminer un Timer de calcul par exemple)
Pour eviter d'avoir toutes ces fonction sur les fenetre on peut extends WindowsAdapter qui lui contient deja l'ensemble des fonctions qui choppent les WindowsEvent et qui implements le WindowsListener et ainsi redefinir qu'une seule des methodes qui nous interesse :
PS : Pour les JComposants je disais que c'etait plus propre de les mettre en attribut mais en aucun cas j'ai mentionné "parce que il extends la classe JFrame", j'ai juste dit que la combinaison des deux était beaucoup plus propre
si je répond ca ne va servir à rien et puis se post est résolu alors moi je clos le débat ici
ps: n'empeche que dans le cas présent ma méthode est tout aussi bien, puisqu'il ne fait que de quitter le programme et en plus balbla, si tu n'utilise pas cette méthode et qu'on laisse le comportement par défaut on peut avoir de sale blague avec les JFrame
[java]grille étrange
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Mon portfolio : https://www.artstation.com/tdugard
Mon portfolio : https://www.artstation.com/tdugard
Mon portfolio : https://www.artstation.com/tdugard