Sur une méthode publique, essayes de plus respecter un format de documentation type javadoc : + //to reinitialize model attribute + public void resetAttribute(){
Sur cette même méthode (UnlettringSelectionModel#resetAttribute), je pense que tu as un gros bug, et que tu supprimes une ligne sur 2 (les lignes paires en l'occurrence) : for (int i = 0; i < selectedRows.size(); i ++){ selectedRows.remove(i); }
Imagines que tu as une liste de 6 éléments : A B C D E F Tu supprimes l'élément à l'index 0 (A). Tous les éléments alors APRÈS A sont donc "déplacés" vers la gauche. B a alors l'index 0, C=1, D=2, ... B C D E F
Tu incrémentes ton index : i=1. Tu supprimes l'élément à l'index 1 (C). B D E F
Tu incrémentes ton index : i=2. Tu supprimes l'élément à l'index 2 (E). B D F
Arrêt de la boucle car ta as attend le .size() = 2.
Tu as donc supprimé tous les éléments pairs de ta liste :)
Le plus simple aurait été d'utiliser une méthode pour vider la liste : selectedRows.clear();
-> Même problème dans LetteringSelectionModel#resetAttribute
J'ai fais une remarque là dessus hier, qui rejoint ce code. "selectedRows" est en fait un 2eme cache qui duplique celui de swing est qui n'est pas réellement cohérent avec la sélection réelle de la table. D'où les incohérence d'interface. Le code qui gère ça me fait peur. Surcharge de plusieurs méthodes du SelectionModel (method add/set/clear...) qui met a jour le cache. Le tout avec un plus 4 modèles pour une seule table (un réel qui délègue aux 3 autres suivant une option). Alors qu'un simple <ListSelectionListener OnValueChanged="updateSolde()" /> serait tellement plus simple est toujours cohérent avec la sélection de la table. La surcharge des SelectionModel a du sens seulement pour l'autoselection des lignes (lignes du même lettrages...), mais pas pour la mise à jour des champs (crédit/débit/champ). -- Éric Chatellier