Discussion :

[javan00b]

Bonjour,

j'ai une Jtable avec un modele qui permet d'ajouter/supprimer dynamiquement des objets qui se materialisent sous forme de rows

donc lorsque je veux ajouter un objet sur la Jtable je l'ajoute d'abord a mon ArrayList dans mon modele et ensuite j'appel la methode: fireTableRowsInserted et fireTableRowsDeleted pour l'operation inverse.

tout sa fonctionne tres bien.

Ensuite, Jai plusieur threads qui doivent lire/modifier des donnees dans le Jtable (thread-safely), lors de la creation des threads je passe via le constructeur de ma classe "thread" un parametre entier qui est en faites l'index de la row/objets sur lequel le thread devra effectuer diverses operations tout au long de l'execution.

par contre lorsque je supprime dynamiquement des objets dans ma Jtable , l'ArrayList reorganise automatiquement les index dans sa structure.

Du coup, mes threads n'effectuent plus leur operations sur les bon objets....

En faites toutes solutions seraient bienvenue

[Chatanga]

Tu pourrais créer une fabrique de références écoutant ton modèle afin de mettre à jour ces dernières en fonction des ajouts / suppressions observées. Par exemple, si l'élément d'index N est supprimé, les index de références supérieurs à N sont tous décrémentés.

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
21
22
class ReferenceFactory implements TableModelListener
{
    interface Reference {
 
        int getIndex();
    }
 
    public ReferenceFactory(TableModel model);
 
    /**
     * La référence retournée est mémorisée et entretenue par cette
     * fabrique de manière à toujours pointer vers le même objet dans
     * le modèle (l'index de la référence est invalidé si l'objet est
     * retiré).
     */
    public Reference create(int index);
 
    /**
     * Arrête d'entretenir la référence données et invalide son index.
     */
    public void destroy(Reference reference);
}

[michon]

tu peux aussi voir pour passer ta JTable en paramètre dans le constructeur de ton thread au lieu du "row" directement... ainsi ton thread pourra lire lui même la valeur du "row" correspondant et pourra donc s'adapter tout seul aux changements d'index...

[javan00b]

Tu pourrais créer une fabrique de références écoutant ton modèle afin de mettre à jour ces dernières en fonction des ajouts / suppressions observées. Par exemple, si l'élément d'index N est supprimé, les index de références supérieurs à N sont tous décrémentés.

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
21
22
class ReferenceFactory implements TableModelListener
{
    interface Reference {
 
        int getIndex();
    }
 
    public ReferenceFactory(TableModel model);
 
    /**
     * La référence retournée est mémorisée et entretenue par cette
     * fabrique de manière à toujours pointer vers le même objet dans
     * le modèle (l'index de la référence est invalidé si l'objet est
     * retiré).
     */
    public Reference create(int index);
 
    /**
     * Arrête d'entretenir la référence données et invalide son index.
     */
    public void destroy(Reference reference);
}

Premierement merci pour ta reponse.

C'est une bonne idee, mais a bien y penser lorsque mes threads effectue des modification sur le Jtable, si je permet la supression dynamique et qu`au meme moment un thread effectue une modification sur un index qui n`existe plus, sa risquerai de causer une exception OutOfBounds, Bien sur sa serai tres dur a reproduire en pratique mais reste que je n`aime pas vraiment sa.

Du coup jai penser que mes threads pourrait contenir directement une reference de l`objet sur lequel ils devront faire diverse operations et je pourrais par la suite apeller manuellement un fireTableDataChanged() tout les x secondes dans un autre thread, puisque de toute facon la pluspart des donnees de mon Jtable sont constamment modifier.

qu`en pense tu ?

[michon]

A vrai dire tu n'as pas besoin d'un thread qui fasse "fireDataChanged()". Il te suffit d'appeler cette méthode après chaque modification de ton modèle... Ainsi ta JTable sera toujours à jour sans avoir besoin d'un thread à cette effet.

[javan00b]

A vrai dire tu n'as pas besoin d'un thread qui fasse "fireDataChanged()". Il te suffit d'appeler cette méthode après chaque modification de ton modèle... Ainsi ta JTable sera toujours à jour sans avoir besoin d'un thread à cette effet.

mon application fait un suivi en "temps reel" de donnees fluctuantes, cest pour cette raison que j'envisageais de faire un thread qui appel FireDataChanged() au 1-2 secondes disons, sinon je me retrouverai avec une dizaine d'appel de FireDataChanged() par seconde, sa serai plutot lourd je pense

[Chatanga]

C'est une bonne idee, mais a bien y penser lorsque mes threads effectue des modification sur le Jtable, si je permet la supression dynamique et qu`au meme moment un thread effectue une modification sur un index qui n`existe plus, sa risquerai de causer une exception OutOfBounds, Bien sur sa serai tres dur a reproduire en pratique mais reste que je n`aime pas vraiment sa.

Le fait que Swing ne soit (généralement) pas thread-safe et que l’EDT doive être utilisé pour mettre à jour l’affichage - deux contraintes bien distinctes au demeurant - a de nombreuses conséquences qui ne sont pas toujours bien comprises. Dans le cas de la mise à jour d’un modèle de table/arbre/etc. utilisé par un composant Swing (JTable/JTree/etc.), ce n’est pas seulement les notifications qui doivent être faites dans l’EDT, mais aussi l’édition du modèle. L’état de ce dernier doit en effet toujours être cohérent avec les notifications émises. Par exemple, si une liste notifie un ajout d’élément portant sa taille à 10, l’éventuelle JList l’affichant pourra très bien demander quelques secondes plus tard (par exemple sur un scrolling de l’utilisateur) la valeur du 10éme élément. Si le modèle est simultanément modifié par un autre thread supprimant des éléments, quand bien même aucune nouvelle notification n’aurait été émise, c’est le crash assuré. Donc le problème n’est pas qu’une de « mes » références devienne invalide, c’est que ton code puisse permettre ce cas de figure qui est fondamentalement problématique.

Du coup jai penser que mes threads pourrait contenir directement une reference de l`objet sur lequel ils devront faire diverse operations et je pourrais par la suite apeller manuellement un fireTableDataChanged() tout les x secondes dans un autre thread, puisque de toute facon la pluspart des donnees de mon Jtable sont constamment modifier.

qu`en pense tu ?

mon application fait un suivi en "temps reel" de donnees fluctuantes, cest pour cette raison que j'envisageais de faire un thread qui appel FireDataChanged() au 1-2 secondes disons, sinon je me retrouverai avec une dizaine d'appel de FireDataChanged() par seconde, sa serai plutot lourd je pense

Puisque l’ensemble de tes données semble évoluer à une fréquence importante et même supérieure à la perception utilisateur, le plus simple semble en effet que ton modèle soit une sorte de snapshot de tes données « métiers » mis à jour périodiquement avec, à chaque fois, une notification indiquant que tout son contenu a changé (pas sa structure car c’est couteux et il faudra donc traiter les ajouts et retraits d’éléments spécifiquement en sachant que seule la taille finale nous intéresse).