Forums : Template et RDF

Tu as essayé de re-écraser la fonction setCellText après un rebuild ?

j'ai pensé à ça, (cf someBuilderListener dans source js) mais même de cette manière, je perds l'évènement.

J'ai un peu avancé dans ma réflexion. Je passe par un listener treeOther.inputField.addEventListener("DOMAttrModified", editListener, true); sur un attribut qui n'est pas documenté inputField dans tree.

en m'inspirant de ça

function startEditing(row, column) {
   if (row < 0 || row >= this.view.rowCount || !column) {
       return;
   }
   if (column.type != Components.interfaces.nsITreeColumn.TYPE_TEXT ||
       column.cycler || !this.view.isEditable(row, column)) {
       return;
   }
   if (this._editingColumn) {
       this.stopEditing();
   }
   var input = this.inputField;
   var box = this.treeBoxObject;
   box.ensureCellIsVisible(row, column);
   var textx = {}, texty = {}, textwidth = {}, textheight = {};
   var coords = box.getCoordsForCellItem(row, column, "text", textx, texty, textwidth, textheight);
   var cellx = {}, cellwidth = {};
   coords = box.getCoordsForCellItem(row, column, "cell", cellx, {}, cellwidth, {});
   var style = window.getComputedStyle(input, "");
   var topadj = parseInt(style.borderTopWidth) + parseInt(style.paddingTop);
   input.top = texty.value - topadj;
   var left, widthdiff;
   if (style.direction == "rtl") {
       left = cellx.value;
       widthdiff = cellx.value + cellwidth.value - textx.value - textwidth.value;
   } else {
       left = textx.value;
       widthdiff = textx.value - cellx.value;
   }
   input.left = left;
   input.height = textheight.value + topadj + parseInt(style.borderBottomWidth) + parseInt(style.paddingBottom);
   input.width = cellwidth.value - widthdiff;
   input.hidden = false;
   input.value = this.view.getCellText(row, column);
   var selectText = function selectText() {input.select();input.inputField.focus();};
   setTimeout(selectText, 0);
   this._editingRow = row;
   this._editingColumn = column;
   this.setAttribute("editing", "true");
}

Maintenant mon problème c'est récupérer la colonne en cours de sélection. le treeOther.selection.currentColumn est null. Aucune idée pourquoi ... j'ai positionné des id sur toutes les colonnes, ça n'a rien changé.

On voit qu'il positionne le inputField avec top et left. J'essaie de faire l'inverse en passant par treeBoxObject.getCellAt()

var row = {};
var col = {};
var childElt = {};
treeOther.treeBoxObject.getCellAt(input.left, input.top, row, col, childElt);

mais les coordonnées sont décalées et j'arrive pas à les recaller : quand je modifie la colonne 1, il ne trouve pas de colonne. Le numéro de ligne est décalé de 1 ou 2 lignes (dépends si la ligne est en haut ou en bas).

Une idée ?

Je me demande si tu ne devrais pas utiliser: nsIXULTreeBuilderObserver Il y a une fonction nommée: onPerformAction qui semble t'avertir lorsqu'une modification est effectuée dans l'arbre. Il y a peut être une piste par là.

Bon, bah, ça marche. un peu compliqué mais efficace.

Je suis passé par l'event listener sur un attribut, mais pas celui que je pensais et pas sur l'élément que je pensais : l'attribut c'est label, l'élément c'est le tableau en lui même !!

Pour le onPerformAction, il va falloir que je vois, peut-être plus simple.

Mais c'est encore une redéfinition d'une méthode existante ... pas sur de choper tous les cas.

commité dans cvs si le code vous intéresse.

NB pour moi : faut vraiment que je fasse un truc plus propre pour la base ...

J'ai essayé la méthode avec le nsIXULTreeBuilderObserver sans résultat. Je suis notifié du click sur les en-tête de colonne, et c'est tout...

Je me demande comment faire ça proprement

Je continue ma recherche...

Je viens de me rendre compte que le flag dont-build-content empêche la capture de l'event DOMAttrModified. Et si on ne met par ce flag, on perd en performance et la capacité de sorting en cliquant sur l'entête...

C'est ennuyeux.

Je viens de me rendre compte que le flag dont-build-content empêche la capture de l'event DOMAttrModified

Je pense que c'est logique car dont-build-content permet justement de ne pas créer les nœuds DOM, donc DOMAttrModified ne devrait pas être déclenché. Il ne faut par conséquent pas modifier le contenu via DOM

J'ai discuté avec laurentj et daim sur irc, ils me conseillent de patcher xulrunner et de fournir cette version avec mon appli.

J'ai regardé le code, ça n'a pas l'air super complexe. J'espère avoir un résultat rapidement.

Quand tu parles de patcher xulrunner, c'est pour avoir une manière simple de récupérer l'évènement de modification d'une valeur dans un tree ?

De mon côté, j'ai continué à avancer et j'ai notamment découvert un bug.

En fait l'évènement se déclenche pour toutes les colonnes même pour les non éditables.

Mon problème était le suivant : quand je modifie une valeur dans les 2 1ère colonnes, en mettant la modif en base, je rebuild le tableau.

Au rebuild du tableau, j'ai un formatage des colonnes crédit et débit qui se fait (rajouter la monnaie, faire un espace pour les milliers ...) et donc je modifie ... l'attribut label de chaque ligne directement. Cela provoque un évènement DOMAttrModified pour l'attribut label. Ca fait une jolie petite boucle inifini.

Avant de prendre en compte la modification, je vérifie donc que la nouvelle valeur de l'évènement correspond effectivement à la valeur actuelle de la cellule sélectionnée.