Bonjour,
j'ai une JTable, dont le modèle est une sous classe de
AbstactTableModel.
Pour tout ce qui est interaction utilisateur (ajout, suppresion,
modification) tout va bien.
Mais il se trouve que j'ai à créer un modèle initial à partir de
données sérialisées.
Je fait dont un setModel(monModel) sur la JTable après avoir créé
monModel.
Et la la table est déséspérément vide, alors que je suis certain que
le
modèle contient bien les données à afficher et répond correctement à
toute les appels des méthode de AbstactTableModel.
Mes données(qui étaient cachées) apparaisse ensuite des que j'ajoute
une ligne, grâce à un bouton que j'ai prévu a cet effet.
J'ai essayé tout les fireTable* possible, mais rien y fait, d'ailleur
je pensais qu'un setModel suffirait à faire le boulot.
Si quelqu'un à une solution, pendant qu'il me reste en core des
cheveux ;)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Prin
Salut, j'ai utilisé la méthode fireTableDataChanged() de mon modèle avec succès pour les chargements de données.
Je suis exactement dans le même cas que toi, modèle qui hérite de AbstractTableModel, données chargées depuis un serveur via la sérialisation. Mon modèle implémente également TableModelListener et ne travaille pas avec les données dans un tableau mais plutot avec un vecteur que je trouve plus pratique à manipuler.
Olivier
papFurax wrote:
Bonjour, j'ai une JTable, dont le modèle est une sous classe de AbstactTableModel. Pour tout ce qui est interaction utilisateur (ajout, suppresion, modification) tout va bien.
Mais il se trouve que j'ai à créer un modèle initial à partir de données sérialisées. Je fait dont un setModel(monModel) sur la JTable après avoir créé monModel. Et la la table est déséspérément vide, alors que je suis certain que le modèle contient bien les données à afficher et répond correctement à toute les appels des méthode de AbstactTableModel.
Mes données(qui étaient cachées) apparaisse ensuite des que j'ajoute une ligne, grâce à un bouton que j'ai prévu a cet effet. J'ai essayé tout les fireTable* possible, mais rien y fait, d'ailleur je pensais qu'un setModel suffirait à faire le boulot.
Si quelqu'un à une solution, pendant qu'il me reste en core des cheveux ;)
Salut, j'ai utilisé la méthode fireTableDataChanged() de mon modèle avec
succès pour les chargements de données.
Je suis exactement dans le même cas que toi, modèle qui hérite de
AbstractTableModel, données chargées depuis un serveur via la
sérialisation. Mon modèle implémente également TableModelListener et ne
travaille pas avec les données dans un tableau mais plutot avec un
vecteur que je trouve plus pratique à manipuler.
Olivier
papFurax wrote:
Bonjour,
j'ai une JTable, dont le modèle est une sous classe de
AbstactTableModel.
Pour tout ce qui est interaction utilisateur (ajout, suppresion,
modification) tout va bien.
Mais il se trouve que j'ai à créer un modèle initial à partir de
données sérialisées.
Je fait dont un setModel(monModel) sur la JTable après avoir créé
monModel.
Et la la table est déséspérément vide, alors que je suis certain que
le
modèle contient bien les données à afficher et répond correctement à
toute les appels des méthode de AbstactTableModel.
Mes données(qui étaient cachées) apparaisse ensuite des que j'ajoute
une ligne, grâce à un bouton que j'ai prévu a cet effet.
J'ai essayé tout les fireTable* possible, mais rien y fait, d'ailleur
je pensais qu'un setModel suffirait à faire le boulot.
Si quelqu'un à une solution, pendant qu'il me reste en core des
cheveux ;)
Salut, j'ai utilisé la méthode fireTableDataChanged() de mon modèle avec succès pour les chargements de données.
Je suis exactement dans le même cas que toi, modèle qui hérite de AbstractTableModel, données chargées depuis un serveur via la sérialisation. Mon modèle implémente également TableModelListener et ne travaille pas avec les données dans un tableau mais plutot avec un vecteur que je trouve plus pratique à manipuler.
Olivier
papFurax wrote:
Bonjour, j'ai une JTable, dont le modèle est une sous classe de AbstactTableModel. Pour tout ce qui est interaction utilisateur (ajout, suppresion, modification) tout va bien.
Mais il se trouve que j'ai à créer un modèle initial à partir de données sérialisées. Je fait dont un setModel(monModel) sur la JTable après avoir créé monModel. Et la la table est déséspérément vide, alors que je suis certain que le modèle contient bien les données à afficher et répond correctement à toute les appels des méthode de AbstactTableModel.
Mes données(qui étaient cachées) apparaisse ensuite des que j'ajoute une ligne, grâce à un bouton que j'ai prévu a cet effet. J'ai essayé tout les fireTable* possible, mais rien y fait, d'ailleur je pensais qu'un setModel suffirait à faire le boulot.
Si quelqu'un à une solution, pendant qu'il me reste en core des cheveux ;)
potonnier
Olivier Prin wrote in message news:<buj9i5$t6d$...
Salut, j'ai utilisé la méthode fireTableDataChanged() de mon modèle avec succès pour les chargements de données.
Moi aussi! Et ça marche sans problème, tant que je ne change pas le modèle, d'où mon post.
Je suis exactement dans le même cas que toi, modèle qui hérite de AbstractTableModel, données chargées depuis un serveur via la sérialisation. Mon modèle implémente également TableModelListener et ne travaille pas avec les données dans un tableau mais plutot avec un vecteur que je trouve plus pratique à manipuler.
C'est l'avantage d'utiliser un modèle, on met la strucure de donnée qu'on veut derrière. Effectivement on est dans le même cas. J'ai résolu mon problème: avant je réinstanciait la JTable (je recréait tout un Panel de mon appli) et maintenant je ne met à jour que le modèle, et ça marche parfaitement.
C'est vrai que c'est plus logique, mais je ne comprends pas pourquoi ça ne marchait pas en reconstruisant le Panel (ça marche bien la première fois pourtant!).
Olivier
Olivier Prin <oprinNO_SPAM@mixcom.fr> wrote in message news:<buj9i5$t6d$1@s1.read.news.oleane.net>...
Salut, j'ai utilisé la méthode fireTableDataChanged() de mon modèle avec
succès pour les chargements de données.
Moi aussi! Et ça marche sans problème, tant que je ne change pas le
modèle, d'où mon post.
Je suis exactement dans le même cas que toi, modèle qui hérite de
AbstractTableModel, données chargées depuis un serveur via la
sérialisation. Mon modèle implémente également TableModelListener et ne
travaille pas avec les données dans un tableau mais plutot avec un
vecteur que je trouve plus pratique à manipuler.
C'est l'avantage d'utiliser un modèle, on met la strucure de donnée
qu'on veut derrière.
Effectivement on est dans le même cas.
J'ai résolu mon problème:
avant je réinstanciait la JTable (je recréait tout un Panel de mon
appli) et maintenant je ne met à jour que le modèle, et ça marche
parfaitement.
C'est vrai que c'est plus logique, mais je ne comprends pas pourquoi
ça ne marchait pas en reconstruisant le Panel (ça marche bien la
première fois pourtant!).
Olivier Prin wrote in message news:<buj9i5$t6d$...
Salut, j'ai utilisé la méthode fireTableDataChanged() de mon modèle avec succès pour les chargements de données.
Moi aussi! Et ça marche sans problème, tant que je ne change pas le modèle, d'où mon post.
Je suis exactement dans le même cas que toi, modèle qui hérite de AbstractTableModel, données chargées depuis un serveur via la sérialisation. Mon modèle implémente également TableModelListener et ne travaille pas avec les données dans un tableau mais plutot avec un vecteur que je trouve plus pratique à manipuler.
C'est l'avantage d'utiliser un modèle, on met la strucure de donnée qu'on veut derrière. Effectivement on est dans le même cas. J'ai résolu mon problème: avant je réinstanciait la JTable (je recréait tout un Panel de mon appli) et maintenant je ne met à jour que le modèle, et ça marche parfaitement.
C'est vrai que c'est plus logique, mais je ne comprends pas pourquoi ça ne marchait pas en reconstruisant le Panel (ça marche bien la première fois pourtant!).
Olivier
Olivier Prin
Il doit y avoir une méthode repaint() ou validate() à appeler depuis le conteneur si tu changes un composant il me semble.
Sinon pour la JTable, c'est la base du fonctionnement MVC. Il ne faut pas changer le Panel (View) quand ce que tu veux mettre à jour est juste de la data (modèle). L'architecture MVC s'occupe de mettre l'affichage à jour dans ce cas.
Olivier
papFurax wrote:
Olivier Prin wrote in message news:<buj9i5$t6d$...
Salut, j'ai utilisé la méthode fireTableDataChanged() de mon modèle avec succès pour les chargements de données.
Moi aussi! Et ça marche sans problème, tant que je ne change pas le modèle, d'où mon post.
Je suis exactement dans le même cas que toi, modèle qui hérite de AbstractTableModel, données chargées depuis un serveur via la sérialisation. Mon modèle implémente également TableModelListener et ne travaille pas avec les données dans un tableau mais plutot avec un vecteur que je trouve plus pratique à manipuler.
C'est l'avantage d'utiliser un modèle, on met la strucure de donnée qu'on veut derrière. Effectivement on est dans le même cas. J'ai résolu mon problème: avant je réinstanciait la JTable (je recréait tout un Panel de mon appli) et maintenant je ne met à jour que le modèle, et ça marche parfaitement.
C'est vrai que c'est plus logique, mais je ne comprends pas pourquoi ça ne marchait pas en reconstruisant le Panel (ça marche bien la première fois pourtant!).
Olivier
Il doit y avoir une méthode repaint() ou validate() à appeler depuis le
conteneur si tu changes un composant il me semble.
Sinon pour la JTable, c'est la base du fonctionnement MVC. Il ne faut
pas changer le Panel (View) quand ce que tu veux mettre à jour est juste
de la data (modèle). L'architecture MVC s'occupe de mettre l'affichage
à jour dans ce cas.
Olivier
papFurax wrote:
Olivier Prin <oprinNO_SPAM@mixcom.fr> wrote in message news:<buj9i5$t6d$1@s1.read.news.oleane.net>...
Salut, j'ai utilisé la méthode fireTableDataChanged() de mon modèle avec
succès pour les chargements de données.
Moi aussi! Et ça marche sans problème, tant que je ne change pas le
modèle, d'où mon post.
Je suis exactement dans le même cas que toi, modèle qui hérite de
AbstractTableModel, données chargées depuis un serveur via la
sérialisation. Mon modèle implémente également TableModelListener et ne
travaille pas avec les données dans un tableau mais plutot avec un
vecteur que je trouve plus pratique à manipuler.
C'est l'avantage d'utiliser un modèle, on met la strucure de donnée
qu'on veut derrière.
Effectivement on est dans le même cas.
J'ai résolu mon problème:
avant je réinstanciait la JTable (je recréait tout un Panel de mon
appli) et maintenant je ne met à jour que le modèle, et ça marche
parfaitement.
C'est vrai que c'est plus logique, mais je ne comprends pas pourquoi
ça ne marchait pas en reconstruisant le Panel (ça marche bien la
première fois pourtant!).
Il doit y avoir une méthode repaint() ou validate() à appeler depuis le conteneur si tu changes un composant il me semble.
Sinon pour la JTable, c'est la base du fonctionnement MVC. Il ne faut pas changer le Panel (View) quand ce que tu veux mettre à jour est juste de la data (modèle). L'architecture MVC s'occupe de mettre l'affichage à jour dans ce cas.
Olivier
papFurax wrote:
Olivier Prin wrote in message news:<buj9i5$t6d$...
Salut, j'ai utilisé la méthode fireTableDataChanged() de mon modèle avec succès pour les chargements de données.
Moi aussi! Et ça marche sans problème, tant que je ne change pas le modèle, d'où mon post.
Je suis exactement dans le même cas que toi, modèle qui hérite de AbstractTableModel, données chargées depuis un serveur via la sérialisation. Mon modèle implémente également TableModelListener et ne travaille pas avec les données dans un tableau mais plutot avec un vecteur que je trouve plus pratique à manipuler.
C'est l'avantage d'utiliser un modèle, on met la strucure de donnée qu'on veut derrière. Effectivement on est dans le même cas. J'ai résolu mon problème: avant je réinstanciait la JTable (je recréait tout un Panel de mon appli) et maintenant je ne met à jour que le modèle, et ça marche parfaitement.
C'est vrai que c'est plus logique, mais je ne comprends pas pourquoi ça ne marchait pas en reconstruisant le Panel (ça marche bien la première fois pourtant!).