Discussion :

[Ima123]

Bonjour,

Qui a une idée sur comment faire un Tableviewer avec nombre de colonnes variable ? J'ai cherché partout mais je n'ai rien trouvé. Ce que je veux faire est afficher dans un TableViewer une liste de valeurs qui a une taille variable.

Merci.

[joel.drigo]

Salut,

Est-ce que le nombre de colonnes varie lorsque le TableViewer est affiché (on peut ajouter ou supprimer des colonnes), est-ce que le nombre de colonnes est différent pour chaque élément, ou est-il simplement différent (mais le même pour tous les élements) à la construction du TableViewer ? Ou peut-être le besoin est-il simplement de pouvoir cacher/afficher des colonnes (comme on fait dans l'Explorer de Windows par exemple) ?

Question subsidiaire : le TableViewer est-il layouté par un TableColumnLayout ?

Avant de décrire le principe, note qu'il existe un composant très puissant, appelé NatTable qui permet de faire plus ou moins ce qu'on ferait avec Excel, qui donc pourrait permettre plus facilement de faire une table avec nombre de colonnes variables.

Pour le TableViewer, ke vais décrire le principe au cas simple : un nombre différent de colonnes à la construction, mais fixe ensuite. Le principe de base reste applicable, mais il faudra éventuellement gérer par événement l'impact des variations, pour rafraîchir le TableViewer (display et layout).

La gestion du nombre de colonnes passe par 2 éléments essentiellement :

• Le LabelProvider qui permet au TableViewer de connaître les valeurs à afficher pour chaque cellule, ou les styles éventuellement (on peut utiliser aussi des CellLabelProvider, mais le principe de base est le même ) ;
• Les TableColumn qui constituent les définitions de colonnes

Pour le LabelProvider, c'est simple, il suffit de gérer les index par rapport à un modèle qui tient compte de la variabilité.

On a 2 méthodes (ou 3 méthodes si on implémente ITableValueProvider, voire plus si on veut gérer du style, mais le principe est le même pour toutes les méthodes) dans ITableLabelProvider. La méthode getColumnText(Object element, int columnIndex) pour donner le texte à afficher pour une cellule, et le pendant getColumnImage()

Par exemple, pour getColumnText, et le cas static, on pourra faire quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
        @Override
	public String getColumnText(Object element, int columnIndex) {
		String text = null;
		if ( element instanceof MachinTruc ) {
			MachinTruc machinTruc = (MachinTruc)element;
			switch (columnIndex) {
			case 0:
				text = machinTruc.getXxx();
				break;
			case 1:
				text = machinTruc.getYyy();
				break;
                        // etc...
			default:
				break;
			}
		}
		return text;
	}

Avec un nombre de colonnes variables, on a un nombre de "columnIndex" non fixe. On pourra gérer ça par exemple avec une classe qui permet de connaitre pour un type d'objet donné, la valeur correspondant à l'index. Tous les index en dehors de l'intervalle donneront simplement une valeur nulle.

Dans le cas général, on peut faire une classe qui définit les colonnes d'un objet qui aura donc une méthode du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public String getText(T element, int index) {
        // code
}

Dans le LabelProvider, on aura plutôt :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
@Override
	public String getColumnText(Object element, int columnIndex) {
		String text = null;
                ColumnManager columnManager = getColumnManager( element ); // on détermine le composant permettant de connaître les valeurs de l'élément pour chaque index (par exemple, en utilisant une Map<Class<?>, ColumnManager>)
                if ( columnManager == null ) {
                     text = null;
                }
                else {
                     text = columnManager.get(columnManager.toType(element), columnIndex); // on délègue l'obtention des valeurs au composant
                }
		return text;
	}

Par exemple, on peut faire une classe abstraite avec cette méthode abstraite et implémenter chaque cas concret par un switch comme ci-dessus, on faire une classe "configurable" qui a une List de définition de colonnes.
Ainsi, le LabelProvider va juste déléguer l'obtention de la bonne valeur à un composant qui saura combien de colonnes il faut afficher pour un élément donné.

Le second aspect est la création des TableColumn. Si d'habitude on crée les TableColumn avec soit une boucle, soit une séquence d'appels qui font, en résumé, un new TableColumn(...), pour le cas simple il faudra simplement pouvoir connaître le nombre maximum de colonnes, et déterminer les configurations de chacune dynamiquement et utiliser une boucle pour les construire.

Par extension, pour faire varier le nombre de colonnes en cours d'affichage, on utilisera des new TableColumn() pour créer des colonnes, des dispose() sur les instances des TableColumn pour les supprimer, et éventuellement agir sur les index des colonnes à droite de la nouvelle colonne ou de la colonne supprimée. Puis faire tout ce qui faut pour rafraîchir les différents composant (comme le TableColumnLayout par exemple).

[Ima123]

en faite ce que je veux exactement c est par exemple si j ai une classe qui contient une liste de voiture avec leurs données differentes je veux dans une autre classe qui contient une table avec les noms des voitures et a chaque fois quand je clique sur un nom il m'affiche une table qui contient dans les noms d colonnes les données du voiture et dans chaque colonne les valeurs de ces données

[joel.drigo]

Le nombre de données de chaque voiture est différents c'est ça ? Et la table qui affiche ces données est toujours visibles, donc tu voudrais pouvoir mettre à jour la table à chaque sélection d'une nouvelle voiture, en résumé. Et bien, si c'est bien ça, c'est bien le sens de ma réponse (mais en résumé ça pourrait être tout simplement recréer la table à chaque nouvelle sélection, comme dans le cas standard).

Cependant, je pense qu'il serait beaucoup plus pratique, et mieux adapté à ce que tu veux faire, d'utiliser une Property View, surtout si tu es dans le cadre d'une application RCP. C'est dynamique, flexible, ça gère également les arbres, et c'est plutôt simple à mettre en place.