Alut la cie
Un truc marrant a essayer...
L'événement onblur se déclanche logiquement avant l'événement onfocus, comme le confirme d'ailleur le SDK d'IE.
Mais j'ai eu une petite surprise en voulant m'en assurer au préalable.
Faites l'expérience vous-mêmes. Pour cela, créez deux control input-text, donnez leur une valeur pour les identifier, et attribuer leur chacun les événement onfocus et onblur comme suit :
Executez la page, et là, hôôôô surprise
Code JavaScript : 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 function whenFocus () { alert("Go in to " + event.srcElement.value); return true; } function whenBlur () { alert("Go out from " + event.srcElement.value); return true; } myCtrl1.onfocus = whenFocus; myCtrl1.onblur = whenBlur; myCtrl2.onfocus = whenFocus; myCtrl2.onblur = whenBlur;... la boite de dialogue du onfocus s'affiche avant celle du onblur.
Changer maintenant le code pour avoir ceci :
On ajoute un petit compteur pour s'assurer du séquencement réel des choses. Et là, hooo... Re-Surprise
Code JavaScript : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14 function whenFocus () { ++count; alert("Go in to " + event.srcElement.value + " (" + count + ")"); return true; } function whenBlur () { ++count; alert("Go out from " + event.srcElement.value + " (" + count + ")"); return true; }Bien que la boite de message de onfocus s'affiche en première, le compteur qu'elle affiche est plus grand que la valeur du compteur de la boite de message de onblur. Donc bien quelle s'affiche en premier, son affichage n'a été invoqué qu'en dernier.
Encore plus fort maintenant.
Si vous placer l'instruction d'incrémentation du compteur aprés l'instruction alert, les deux boites de message, pour onblur et onfocus afficheront la même valeur, et à l'occurence suivante, le compteur aura bien sûre été augmenté de deux.
Bilan : l'affichage d'une boite de message suspend l'execution du gestionnaire d'événement de onblur, et pendant ce temps, l'événement onfocus est levé, ce qui execute le gestionnaire d'événement de onfocus. Comme celui-ci n'est suspendu par rien (car pendant qu'il est suspendu par sa boite de message, aucun événement ne se produit), alors se termine avant le gestionnaire d'événement de onblur qui ne se termine que plus tard.
Hé bien, comme quoi il n'y a pas qu'en programmation système qu'on rencontre des problème de sequencement sensible.
Shématiquement, on a ceci :
Et voilà comment l'execution passe de l'un à l'autre des gestionnaire d'événement.
Code x : 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 (en supposant que c'est myCtrl2 qui a le focus) | Action utilisateur | gestionnaire whenBlur | gestionnaire whenFocus | | ---------------------------------------------------------------------- | clic sur myCtrl1 | déclenchement onblur | (inerte) | | l'execution commence | (inerte) | | appel de alert | (inerte) | | suspension | (inerte) | | (suspendu) | déclenchement onfocus | | (suspendu) | l'execution commence | | (suspendu) | appel de alert | | (suspendu) | le message s'affiche | | (suspendu) | termine son execution | | reprise de l'execution | (interte) | | le message s'affiche | (inerte) | | termine son execution | (inerte) | | (inerte) | (inerte)
Alors attention au instruction qui peuvent suspendre l'execution d'un gestionnaire d'événement, et lui faire souffler la place par un autre![]()
La prochaine fois je vous parle du dossier caché des XFiles (ça changera)
Partager