Renderer n'est jamais appelé + question

Version imprimable

Bonjour,

J'ai un renderer de JTable qui n'est pas appelé... J'ai déjà effectué ce genre de traitement dans le passé, sans problème, mais pas cette fois ça ne fonctionne pas.

Voici le code :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public MonPnl() {
 
        ArrayList<Affaire> alTest = new ArrayList<Affaire>();
        // Initialisation de alTest, les valeurs sont les bonnes
 
        tab = new JTable(new TabModel(alTest));
 
        tab.setDefaultRenderer(String.class, new TabRenderer());
        System.out.println("on a rajouté le renderer : " + tab.getDefaultRenderer(String.class).getClass().getName());// aucun souci ici, le sysout qui indique ce qu'il faut...
 
        this.add(new JScrollPane(tab));//juste un petit test, sans layout
    }
 
    private class TabModel extends AbstractTableModel {// aucun souci ici, les valeurs sont bonnes
    }
 
    private class TabRenderer extends DefaultTableCellRenderer {
 
        public Component getTableCellRendererComponent(JTable table, Object value, boolean isSelected, boolean hasFocus, int row, int column)
        {
            System.out.println("on lance le renderer"); // n'apparaît jamais ...
            super.getTableCellRendererComponent(table, value, isSelected, hasFocus, row, column);
            //traitement et analyse des données, pour la coloration, etc...
            return this;
        }
    }

Quelqu'un saurait-il m'indiquer comment résoudre ce problème ?

De plus, j'aimerais que certaines cases soient éditables (dans l'AbstractTableModel, pas de problème là-dessus) mais seulement en utilisant un menu déroulant. J'ai donc trouvé une méthode, qui fonctionne :

Code:

1
2
//initialisation de mon JComboBox
this.tab.getColumnModel().getColumn(noColumn).setCellEditor(new DefaultCellEditor(monComboBox));

Ma question est la suivante :
Si je fais ce traitement après :

Code:

tab.setDefaultRenderer(String.class, new TabRenderer());

Est-ce que cela ne va pas "annuler" l'effet du renderer ?

Merci d'avance pour votre aide.

Salut,

à priori je pense que tu n'a pas implémenté la méthode getColumnClass de ton modèle. Par défaut cette méthode renvoit Object.class pour toutes les colonnes.

Comme ton renderer est installé pour la classe String, il n'est jamais sélectionné.

Donc il faut que tu ajoutes à TabModel un truc dans le genre :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 @Override public Class<?> getColumnClass(int columnIndex) { // la liste des index de colonnes dont le type est String (ici par exemple, 0 à 3 switch (columnIndex) { case 0: case 1: case 2: case 3: return String.class; default: return super.getColumnClass(columnIndex); } }
Les "CellEditor" ne remplacent le renderer que pendant l'édition de la cellule (quand elle a le focus il me semble, mais je n'en suis plus très sur).

20/08/2013, 14h41
Nafnlaus

Alleluia !
Oui, ça marche !
Code:

1 2 3 public Class<?> getColumnClass(int columnIndex) { return String.class; }
Je vais essayé concernant les cellEditor, je vous tiens au courant.

Mais d'ailleurs, si jamais dans ce getColumnClass, je définis la colonne X en tant que JComboBox, ça ne fonctionnera pas ? Ou bien elle apparaîtra constamment sous forme d'un JComboBox, c'est ça ? je vais essayer...

Merci beaucoup déjà ! Je mettrai :resolu: dès que j'aurai réussi avec les combobox, et je posterai la solution.
20/08/2013, 14h43
joel.drigo

Citation:

Envoyé par Nafnlaus

Mais d'ailleurs, si jamais dans ce getColumnClass, je défini la colonne X en tant que JComboBox, ça ne fonctionnera pas ? Ou bien elle apparaîtra constamment sous forme d'un JComboBox, c'est ça ? je vais essayer...

Cette méthode sert à indiquer à la JTable les types des données pour chaque colonne, pas la façon de les afficher ou de les saisir.

La notion de jcombobox, à priori pour saisir une valeur sera gérée par le CellEditor.

:ave:

D'accord, merci beaucoup pour toutes ces informations.

Tous fonctionne à présent.

Cependant, d'un point de vue graphique, si la colonne des status indique R, alors le fond doit être vert, écrit en blanc, et si le statut est E, alors c'est en blanc sur fond rouge. Autrement noir sur fond blanc, normal.

J'ai donc ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
public Component getTableCellRendererComponent(JTable table, Object value, boolean isSelected, boolean hasFocus, int row, int column)
        {
            super.getTableCellRendererComponent(table, value, isSelected, hasFocus, row, column);
 
            if(column == 10)//Statut
            {
                if(value == "R")
                {
                    this.setBackground(Color.GREEN);
                    this.setForeground(Color.WHITE);
                }
                else if(value == "E")
                {
                    this.setBackground(Color.RED);
                    this.setForeground(Color.WHITE);
                }
                else
                {
                    this.setBackground(Color.WHITE);
                    this.setForeground(Color.BLACK);
                }
            }
            else if(column == 20)//Démat possible
            {
                if(value == "OUI")
                {
                    this.setForeground(Color.GREEN);
                }
                else if(value == "NON")
                {
                    this.setForeground(Color.RED);
                }
            }
 
            if(table.getModel().getValueAt(row, 10).equals("E"))//si on a le statut excuse, on barre tout en rouge + on écrit en rouge
            {
                this.setForeground(Color.RED);
                //TODO barrer le texte
            }
 
            return this;
        }

Et le comportement est plus que bizarre... La ligne est en fond vert à partir de la colonne 10, et si on clique sur les en-têtes, tout devient vert.

Par contre si on sélectionne la ligne, elle est en bleu (normal, couleur par défaut, grâce au "super.get...", sauf la colonne 10 (normal puisque pour l'instant, je n'ai pas utilisé isSelected) qui est verte...

Je me demande donc pourquoi toutes les autres cases sont vertes passé la colonne 10 ? Elles ne vérifient pourtant pas le test :

Code:

if(column == 10)

je ne comprends pas...

Correction qui a fonctionné, mais je ne sais pas pourquoi...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
public Component getTableCellRendererComponent(JTable table, Object value, boolean isSelected, boolean hasFocus, int row, int column)
        {
            super.getTableCellRendererComponent(table, value, isSelected, hasFocus, row, column);
 
            if(!isSelected)//prise en compte de la sélection
            {
                if(column == 10)//Statut
                {
                    if(value == "R")
                    {
                        this.setBackground(Color.GREEN);
                        this.setForeground(Color.WHITE);
                    }
                    else if(value == "E")
                    {
                        this.setBackground(Color.RED);
                        this.setForeground(Color.WHITE);
                    }
                }
                else if(column == 20)//Démat possible
                {
                    if(value == "OUI")
                    {
                        this.setForeground(Color.GREEN);
                    }
                    else if(value == "NON")
                    {
                        this.setForeground(Color.RED);
                    }
                }
                else //déplacement du else
                {
                    this.setBackground(Color.WHITE);
                    this.setForeground(Color.BLACK);
                }
 
                if(table.getModel().getValueAt(row, 10).equals("E"))//si on a le statut excuse, on barre tout en rouge + on écrit en rouge
                {
                    System.out.println("la ligne en rouge");
                    this.setForeground(Color.RED);
                    //TODO barrer le texte
                }
            }
 
            return this;
        }

Le renderer garde en mémoire le dernier aspect graphique qu'il a créé ?

Regarde le code de la méthode getTableCellColumnRendererComponent(...) de DefaultTableCellRenderer :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
 public Component getTableCellRendererComponent(JTable table, Object value,
                          boolean isSelected, boolean hasFocus, int row, int column) {
 
	if (isSelected) {
	   super.setForeground(table.getSelectionForeground());
	   super.setBackground(table.getSelectionBackground());
	}
	else {
	    super.setForeground((unselectedForeground != null) ? unselectedForeground 
	                                                       : table.getForeground());
	    super.setBackground((unselectedBackground != null) ? unselectedBackground 
	                                                       : table.getBackground());
	}
 
	setFont(table.getFont());
 
	if (hasFocus) {
            Border border = null;
            if (isSelected) {
                border = UIManager.getBorder("Table.focusSelectedCellHighlightBorder");
            }
            if (border == null) {
                border = UIManager.getBorder("Table.focusCellHighlightBorder");
            }
            setBorder(border);
 
	    if (!isSelected && table.isCellEditable(row, column)) {
                Color col;
                col = UIManager.getColor("Table.focusCellForeground");
                if (col != null) {
                    super.setForeground(col);
                }
                col = UIManager.getColor("Table.focusCellBackground");
                if (col != null) {
                    super.setBackground(col);
                }
	    }
	} else {
            setBorder(getNoFocusBorder());
	}
 
        setValue(value); 
 
	return this;
    }

On voit bien comment il faut gérer les attributs graphiques du renderer en fonction des différents arguments de la méthode et comment on doit les modifier le cas échéant.

Au début, il y a le traitement de la sélection : si tu mets une valeur de background et/ou de foreground sans prendre en compte isSelected, tu modifies le comportement standard de l'affichage de lignes sélectionnées. Il faut tenir compte donc de ce booléen en plus des index de colonnes et des valeurs. Idem un peu plus loin, si la cellule à le focus et si la cellule est éditable et si elle n'est pas sélectionnée.

A noter que c'est la même instance de renderer qui est utilisée à chaque fois et que l'appel de setForeground et setBackground "sauve" la couleur passée en argument, donc il faut que tu affectes les background et les foreground pour tous les cas : donc si tu as un truc comme tu as :

Code:

1
2
3
4
5
6
7
8
9
10
11
else if(column == 20)//Démat possible
			{
				if(value == "OUI")
				{
					this.setForeground(Color.GREEN);
				}
				else if(value == "NON")
				{
					this.setForeground(Color.RED);
				}
			}

il faut toujours qu'il y ait un else final qui mets la valeur par défaut.

Le plus simple étant d'écrire un truc comme ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
 
if( isSelected ) {
    // faire le cas des lignes sélectionnées
}
else {
Color foreGround = table.getForeground();
Color backGround = table.getBackground();
 
if(column == 10)//Statut
			{
				if("R".equals(value) )
				{
					foreGround = Color.GREEN;
					backGround  = Color.WHITE;
				}
				else if("E".equals(value))
				{
					background = Color.RED;
					foreground = Color.WHITE;
				}
				else
				{
					background = Color.WHITE;
					foreground = Color.BLACK;
				}
			}
			else if(column == 20)//Démat possible
			{
				if("OUI".equals(value))
				{
					foreground = Color.GREEN;
				}
				else if("NON".equals(value) )
				{
					foreground = Color.RED;
				}
			}
 
			if("E".equals(table.getModel().getValueAt(row, 10)))//si on a le statut excuse, on barre tout en rouge + on écrit en rouge
			{
				foreground = Color.RED;
				//TODO barrer le texte
			}
 
setForeground(foreground);
setBackground(background);
}

Citation:

Envoyé par Nafnlaus

Le renderer garde en mémoire le dernier aspect graphique qu'il a créé ??

oui. Regarde les méthode setForeground et setBackground de DefaultTableCellRenderer :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 /** * Overrides <code>JComponent.setForeground</code> to assign * the unselected-foreground color to the specified color. * * @param c set the foreground color to this value */ public void setForeground(Color c) { super.setForeground(c); unselectedForeground = c; } /** * Overrides <code>JComponent.setBackground</code> to assign * the unselected-background color to the specified color. * * @param c set the background color to this value */ public void setBackground(Color c) { super.setBackground(c); unselectedBackground = c; }
et la méthode getTableCellRendererComponent() (postée précédemment)

Toujours utile de regarder les sources des classes de java pour comprendre comment ça marche.

En bonus, c'est bon pour afficher le texte barré ? Tu sais comment faire ?

20/08/2013, 15h52
Nafnlaus
Ok très bien merci beaucoup :)

Merci pour toutes ces infos et conseils !

Euh pour le texte barré, je viens de trouver un truc sur le net
Code:

1 2 3 Font police = new Font("Times New Roman", Font.PLAIN, 24); AttributedString str_attribut = new AttributedString(texte); str_attribut.addAttribute(TextAttribute.STRIKETHROUGH, police);
Je vais essayer un truc dans ce genre là.
Eventuellement une autre méthode à proposer ?

Et il va aussi falloir que je fasse un JComboBox dans la JTable, mais qui ne propose que les choix dont on a commencé à taper les lettres (je ne suis pas sûr d'être très clair là) mais j'ai aussi trouvé un autre truc https://today.java.net/pub/a/today/2...omboboxes.html
Donc je vais essayer de combiner ça avec le

Code:

this.tab.getColumnModel().getColumn(noColumn).setCellEditor(new DefaultCellEditor(monComboBox))

Et je vais bien voir ce que ça va faire, mais pour l'instant, je galère à l'installer (Glazed Lists), ça n'a pas l'air d'être un "external jar" comme j'ai déjà eu l'occasion d'utiliser.

Si tu as des suggestions ?

En tous les cas, merci encore pour tout ce que tu m'as indiqué.

L'utilisation de la classe AttributedString est une méthode assez clean mais elle va t'obliger d'écrire ton propre renderer, parce ce que cette classe s'utilise bas niveau avec un drawString() dans le contexte graphique, complètement. Bon, tu seras peut être pas obligé de gérer le cas générique, mais ça fait quand même pas mal de boulot.

Un autre possibilité est d'utiliser directement le même attribut sur la classe Font, mais cà ne fonctionne que sur les plateformes ou cet attribut est supporté.

Je te propose donc l'astuce hyper simple suivante passer par du html :
Code:

1 2 3 4 5 if("E".equals(table.getModel().getValueAt(row, 10)))//si on a le statut excuse, on barre tout en rouge + on écrit en rouge { ... setValue("<html><strike>"+ value + "</strike>"); }

20/08/2013, 16h12
Nafnlaus

Je n'ai pas tout compris la première partie mais pour ce qui est du HTML, je connaissais pour les JButton, mais je pensais pas que ça fonctionnait pour les JTable !

Ca a fonctionné parfaitement... merci infiniment.

En une seule journée, tu as réussi à régler tous mes problèmes :ccool:
20/08/2013, 16h17
joel.drigo

Citation:

Envoyé par Nafnlaus

Et il va aussi falloir que je fasse un JComboBox dans la JTable, mais qui ne propose que les choix dont on a commencer à taper les lettres (euh, je sais pas si c'est très clair là :?)

Oui c'est ce qu'on appelle l'autocompletion. Y'a un exemple d'autocompletion dans la TextAreaDemo là : http://docs.oracle.com/javase/tutori.../textarea.html. Bien sur l'approche est légèrement différente que pour une combo, ou il faut filtrer les choix déjà présent dans la combo au lieu d'afficher des choix possibles, mais l'idée est la.

On doit pouvoir trouver des implémentations toutes faites pour des combo qui sont relativement simple. Je ne suis plus très au fait de ce genre de truc, vu que je bosse exclusivement sur SWT depuis des années, mais c'est sur que ça se trouve rapidos par google en tapant java combo autocompletion. La GlazedList que tu as trouvé me semble pas mal en regardant vite fait.

EDIT : tiens v'la un source que tu dois pouvoir adapter rapidement : http://www.dzone.com/snippets/autoco...-combobox-java
20/08/2013, 16h32
Nafnlaus

Je viens de lire le lien, et la méthode de complétion met en œuvre des threads je crois (interface Runnable), donc je suis pas chaud pour ça... Je vais voir sur Google, maintenant que je connais le terme correct pour ça.

HS : Saurais-tu m'expliquer (succinctement) les raisons pour lesquelles tu travailles sur SWT ?
Quels sont les différences/avantages avec ce que j'utilise là ?
20/08/2013, 16h50
joel.drigo

Les raisons pour lesquelles je travaille sous SWT/JFace est que l'application sur laquelle je travaille est une application RCP, et que ça semblait plus naturel de travailler sous SWT lorsqu'on a démarré le produit. On aurait pu travailler en awt/swing. En l'occurence, on intègre quelques composants en swing (Ephox EditLive par exemple, Piccolo, et une API de PageTurner que j'ai développé moi même).

S'il y a des différences entre SWT/JFACE et AWT/SWING, à part quelques détails dans la façon de structurer les UI et la gestion de layout, et quelques contraintes (la synchro obligatoire sur le thread graphique SWT et surtout l'obligation de disposer des composants pour libérer les handles) mais rien qui ne deviennent un réflexe en quelque temps, les différences, les avantages et les inconvénients se situent surtout à ces niveaux :

- le rendu SWT/JFACE est natif OS, donc plus intégré, mais aussi plus limité, puisque dépendant de la plateforme
- le rendu AWT/SWING est plus générique, commun à toutes les plateformes, mais le pendant est que des éléments spécifiques à la plateforme peuvent être galère à reproduire (et dans une application professionnelle face à des clients qui ne jurent que par leur sacro saint macintosh, c'est un argument de poids)

- les possibilités de s'écarter de l'API d'origine est peut être plus souple en AWT/SWING qu'en SWT/JFACE, mais on arrive à faire de très belle chose sans trop problème : il y a même des modules qui permet de faire du SWT en utilisant des classes identiques à celle de SWING

- je déplore que les viewers ne soient pas de vrais composants MVC autant que ceux de SWING, mais on est pas si loin, et on peut arriver à un résultat similaire. on trouve en outre des plugins qui propose des implémentations de viewers utilisant un Modèle de données évenementiel, qui fait qu'on est quasiment en MVC à la swing.

- on peut aussi regretter dans certains cas que beaucoup d'API SWT/SWING de widget soient des plugins, ce qui peut être génant quand on veut faire des applications non RCP. mais pour avoir fait moi même des applis SWT autonome, j'ai pu en intégrer (ou plutot désintégrer en l'occurence ;)) certains commes la gallerie en 15 min.

- après sur certains composants particuliers on trouvera des avantages d'un coté ou de l'autre (je pense par exemple au html dans les labels sous SWING et au StyledText et TextLayout de SWT) : dans ce contexte, l'avantage de SWT est qu'on peut toujours intégrer un composant AWT au sein d'une interface SWT alors que l'inverse est extrêmement plus limité.
20/08/2013, 16h59
Nafnlaus

En tout cas, merci pour tout, je vais potasser tout ça, et je te remercie sincèrement et énormément pour tous ces renseignements/infos/conseils/aides...