Forums : Xul, Xbl, JS...

attribut disabled ? En particulier sur la <command> associée à ton key..

Ben bien sûr !!!! Merci

function offkey()
{
var vl_key=document.getElementById("supr-key");
vl_key.setAttribute("disabled","true");
}

et

function donkey()
{
var vl_key=document.getElementById("supr-key");
vl_key.setAttribute("disabled","false");
}

suis vraiment un âne parfois !!!

Plutôt que vl_key.setAttribute("disabled","false"); il vaut mieux faire:

vl_key.removeAttribute("disabled");

pourquoi vaut-il mieux ? Pour la propreté de l'écriture ? Pour la rapidité ? Pour ?

Je ne sais pas réelement pourquoi, mais il y a apparement des cas ou mettre l'attribut à faux ne fonctionne pas.

@thefab:

Je confirme.

C'est le "apparemment" qui me gène. Il me semble avoir aussi constaté que dans certains cas, sur certains objets, sur certaines propriétés que l'on fasse

toto.disabled=true

ou

toto.disabled="true"

ou

toto.setAttribute("disabled","true")

on avait un comportement différent ... mais je n'arrive pas à déterminer un paradigme. Je pensais que tous les objets ne réagissaient pas de la même manière. A votre avis, un objet "key" peut-il réagir une fois à setattribute(disabled="false") et une fois non ?

Il me semble que : toto.disabled=true change la valeur de disabled pour le context JS seulement (donc si on fait ensuite un getArrtibute, on recupere l'attribut "physiquement" present dans le xul) 2eme cas: je seche toto.setAttribute("disabled","true") change la valeur dans le DOM et est "normalement" (je sais pas pk c'est pas toujours le cas) hérité par la propriété JS.

cela dépend des balises xul (donc du xbl qu'il y a derrière la plupart du temps).

Parfois, modifier la proprieté disabled modifie aussi l'attribut disabled. Et parfois non...

Bref c'est un peu empirique. "La" meilleure solution étant donc d'utiliser celle qui fonctionne dans le contexte ...