Savez-vous ressusciter Internet Explorer?
J'ai un script JS qui introduit volontairement des délais (au choix de
l'utilisateur) pour permettre d'admirer ce qui est affiché (et faire des
captures d'écran etc).
(Z'inquiétez pas pô - z'allez le voir quand il sera perfectionné ;-))
Habituellement, après un certain temps, le navigateur considère que le
script est coincé dans une boucle et t'en prévient; te donnant ainsi
l'occasion de le terminer.
Or, selon le navigateur les résultats sont très variables:
1. Opéra n'a rien à dire; il veut bien patienter jusqu'à la nouvelle lune.
2. La grande famille Gecko (Netscape, Mozilla, SeaMonkey, Firefox) est
paramétrable: il suffit de régler "dom.max_script_run_time" à la valeur
voulue.
3. En revanche Internet Explorer (6) ne semble réagir à rien: j'en ai
marre de fouiller 10000 clés dans la BDR pour rien trouver. Quelqu'un
sait-il ce qu'il faut modifier (ou probablement plutôt rajouter) pour
modifier son comportement?
Merci pour vos délais.
CriCri
--
bitwyse [PGP KeyID 0xA79C8F2C]
Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse
mais aurait préféré ne pas la savoir.
http://www.le-maquis.net
le ressuciter non, lui faire exécuter quelque chose "plus tard" oui, c'est aussi simple que "setTimeout()" - bcp plus propre qu'une boucle sans fin.
3. En revanche Internet Explorer (6) ne semble réagir à rien
si il réagit (détecte) les comportements anormaux, un script qui ne produit rien durant un long temps est un comportement anormal.
pour modifier son [IE] comportement?
je pense que c'est votre stratégie "d'attente" qu'il faut modifier.
Sylvain.
CriCri
Doug713705 a écrit :
Ne serait il pas plus simple de faire en sorte que l'action suivante soit imputée à l'utilisateur
Il n'y a pas nécessairement une "action suivante": l'utilisateur peut se contenter simplement de regarder le déroulement au ralenti.
plutôt que de bloquer un "processus" par une boucle à longueur variable laissée au bon soin de l'utilisateur ?
Le processus n'est jamais bloqué (quoi qu'il en soit il s'achève dans quelques millisecondes): c'est uniquement la durée de l'affichage de la prochaine étape qui est laissée au gré de l'utilisateur.
FU2 chez les javascripteurs.
FU2 refusé: s'agissant d'un paramétrage de IE, spécifique à Windows.
-- bitwyse [PGP KeyID 0xA79C8F2C] Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse mais aurait préféré ne pas la savoir. http://www.le-maquis.net
Doug713705 a écrit :
Ne serait il pas plus simple de faire en sorte que l'action suivante
soit imputée à l'utilisateur
Il n'y a pas nécessairement une "action suivante": l'utilisateur peut se
contenter simplement de regarder le déroulement au ralenti.
plutôt que de bloquer un "processus" par une boucle à longueur
variable laissée au bon soin de l'utilisateur ?
Le processus n'est jamais bloqué (quoi qu'il en soit il s'achève dans
quelques millisecondes): c'est uniquement la durée de l'affichage de la
prochaine étape qui est laissée au gré de l'utilisateur.
FU2 chez les javascripteurs.
FU2 refusé: s'agissant d'un paramétrage de IE, spécifique à Windows.
--
bitwyse [PGP KeyID 0xA79C8F2C]
Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse
mais aurait préféré ne pas la savoir.
http://www.le-maquis.net
Ne serait il pas plus simple de faire en sorte que l'action suivante soit imputée à l'utilisateur
Il n'y a pas nécessairement une "action suivante": l'utilisateur peut se contenter simplement de regarder le déroulement au ralenti.
plutôt que de bloquer un "processus" par une boucle à longueur variable laissée au bon soin de l'utilisateur ?
Le processus n'est jamais bloqué (quoi qu'il en soit il s'achève dans quelques millisecondes): c'est uniquement la durée de l'affichage de la prochaine étape qui est laissée au gré de l'utilisateur.
FU2 chez les javascripteurs.
FU2 refusé: s'agissant d'un paramétrage de IE, spécifique à Windows.
-- bitwyse [PGP KeyID 0xA79C8F2C] Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse mais aurait préféré ne pas la savoir. http://www.le-maquis.net
CriCri
Sylvain SF a écrit :
le ressuciter non, lui faire exécuter quelque chose "plus tard" oui, c'est aussi simple que "setTimeout()" - bcp plus propre qu'une boucle sans fin.
La boucle n'est pas sans fin mais d'une durée choisie par l'utilisateur. Un 'setTimeout' n'empêche pas la poursuite du script mais ne fait que reporter l'exécution d'une nouvelle action.
si il réagit (détecte) les comportements anormaux, un script qui ne produit rien durant un long temps est un comportement anormal.
Non, un script qui maintient l'affichage d'une certaine étape de son déroulement n'a rien d'anormal.
je pense que c'est votre stratégie "d'attente" qu'il faut modifier.
L'attente est destinée à permettre à l'utilisateur d'observer un résultat avant qu'il disparaisse, remplacé par le prochain. C'est parfaitement normal et souhaitable.
-- bitwyse [PGP KeyID 0xA79C8F2C] Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse mais aurait préféré ne pas la savoir. http://www.le-maquis.net
Sylvain SF a écrit :
le ressuciter non, lui faire exécuter quelque chose "plus tard" oui,
c'est aussi simple que "setTimeout()" - bcp plus propre qu'une
boucle sans fin.
La boucle n'est pas sans fin mais d'une durée choisie par l'utilisateur.
Un 'setTimeout' n'empêche pas la poursuite du script mais ne fait que
reporter l'exécution d'une nouvelle action.
si il réagit (détecte) les comportements anormaux, un script qui ne
produit rien durant un long temps est un comportement anormal.
Non, un script qui maintient l'affichage d'une certaine étape de son
déroulement n'a rien d'anormal.
je pense que c'est votre stratégie "d'attente" qu'il faut modifier.
L'attente est destinée à permettre à l'utilisateur d'observer un
résultat avant qu'il disparaisse, remplacé par le prochain. C'est
parfaitement normal et souhaitable.
--
bitwyse [PGP KeyID 0xA79C8F2C]
Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse
mais aurait préféré ne pas la savoir.
http://www.le-maquis.net
le ressuciter non, lui faire exécuter quelque chose "plus tard" oui, c'est aussi simple que "setTimeout()" - bcp plus propre qu'une boucle sans fin.
La boucle n'est pas sans fin mais d'une durée choisie par l'utilisateur. Un 'setTimeout' n'empêche pas la poursuite du script mais ne fait que reporter l'exécution d'une nouvelle action.
si il réagit (détecte) les comportements anormaux, un script qui ne produit rien durant un long temps est un comportement anormal.
Non, un script qui maintient l'affichage d'une certaine étape de son déroulement n'a rien d'anormal.
je pense que c'est votre stratégie "d'attente" qu'il faut modifier.
L'attente est destinée à permettre à l'utilisateur d'observer un résultat avant qu'il disparaisse, remplacé par le prochain. C'est parfaitement normal et souhaitable.
-- bitwyse [PGP KeyID 0xA79C8F2C] Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse mais aurait préféré ne pas la savoir. http://www.le-maquis.net
JePe
> 3. En revanche Internet Explorer (6) ne semble réagir à rien: j'en ai marre de fouiller 10000 clés dans la BDR pour rien trouver. Quelqu'un sait-il ce qu'il faut modifier (ou probablement plutôt rajouter) pour modifier son comportement?
> 3. En revanche Internet Explorer (6) ne semble réagir à rien: j'en ai
marre de fouiller 10000 clés dans la BDR pour rien trouver. Quelqu'un
sait-il ce qu'il faut modifier (ou probablement plutôt rajouter) pour
modifier son comportement?
> 3. En revanche Internet Explorer (6) ne semble réagir à rien: j'en ai marre de fouiller 10000 clés dans la BDR pour rien trouver. Quelqu'un sait-il ce qu'il faut modifier (ou probablement plutôt rajouter) pour modifier son comportement?
"CriCri" a écrit dans le message de news:483b2974$0$916$
Sylvain SF a écrit : > > le ressuciter non, lui faire exécuter quelque chose "plus tard" oui, > c'est aussi simple que "setTimeout()" - bcp plus propre qu'une > boucle sans fin.
La boucle n'est pas sans fin mais d'une durée choisie par l'utilisateur. Un 'setTimeout' n'empêche pas la poursuite du script mais ne fait que reporter l'exécution d'une nouvelle action.
> si il réagit (détecte) les comportements anormaux, un script qui ne > produit rien durant un long temps est un comportement anormal.
Non, un script qui maintient l'affichage d'une certaine étape de son déroulement n'a rien d'anormal.
> je pense que c'est votre stratégie "d'attente" qu'il faut modifier.
Je le pense aussi.
Il faut combiner "setTimeout()" et "setInterval()".
En gros tous les les x interval si l'événement d'arrêt n'est pas survenu lancer la temporisation, à toi de trouver quel évenement doit arrêter ton truc (un click sur la page, un doubleclick ...)
Bonjour,
"CriCri" <bitwyse@leTIRETmaquis.net> a écrit dans le message de news:483b2974$0$916$ba4acef3@news.orange.fr...
Sylvain SF a écrit :
>
> le ressuciter non, lui faire exécuter quelque chose "plus tard" oui,
> c'est aussi simple que "setTimeout()" - bcp plus propre qu'une
> boucle sans fin.
La boucle n'est pas sans fin mais d'une durée choisie par l'utilisateur.
Un 'setTimeout' n'empêche pas la poursuite du script mais ne fait que
reporter l'exécution d'une nouvelle action.
> si il réagit (détecte) les comportements anormaux, un script qui ne
> produit rien durant un long temps est un comportement anormal.
Non, un script qui maintient l'affichage d'une certaine étape de son
déroulement n'a rien d'anormal.
> je pense que c'est votre stratégie "d'attente" qu'il faut modifier.
Je le pense aussi.
Il faut combiner "setTimeout()" et "setInterval()".
En gros tous les les x interval si l'événement d'arrêt n'est pas survenu
lancer la temporisation, à toi de trouver quel évenement doit arrêter
ton truc (un click sur la page, un doubleclick ...)
"CriCri" a écrit dans le message de news:483b2974$0$916$
Sylvain SF a écrit : > > le ressuciter non, lui faire exécuter quelque chose "plus tard" oui, > c'est aussi simple que "setTimeout()" - bcp plus propre qu'une > boucle sans fin.
La boucle n'est pas sans fin mais d'une durée choisie par l'utilisateur. Un 'setTimeout' n'empêche pas la poursuite du script mais ne fait que reporter l'exécution d'une nouvelle action.
> si il réagit (détecte) les comportements anormaux, un script qui ne > produit rien durant un long temps est un comportement anormal.
Non, un script qui maintient l'affichage d'une certaine étape de son déroulement n'a rien d'anormal.
> je pense que c'est votre stratégie "d'attente" qu'il faut modifier.
Je le pense aussi.
Il faut combiner "setTimeout()" et "setInterval()".
En gros tous les les x interval si l'événement d'arrêt n'est pas survenu lancer la temporisation, à toi de trouver quel évenement doit arrêter ton truc (un click sur la page, un doubleclick ...)
Merci pour ta réponse - enfin à la question posée (et non pas d'autres!).
Amicalement CriCri
-- bitwyse [PGP KeyID 0xA79C8F2C] Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse mais aurait préféré ne pas la savoir. http://www.le-maquis.net
Merci pour ta réponse - enfin à la question posée (et non pas d'autres!).
Amicalement
CriCri
--
bitwyse [PGP KeyID 0xA79C8F2C]
Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse
mais aurait préféré ne pas la savoir.
http://www.le-maquis.net
Merci pour ta réponse - enfin à la question posée (et non pas d'autres!).
Amicalement CriCri
-- bitwyse [PGP KeyID 0xA79C8F2C] Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse mais aurait préféré ne pas la savoir. http://www.le-maquis.net
CriCri
Salut
Michel_D a écrit :
Il faut combiner "setTimeout()" et "setInterval()".
En gros tous les les x interval si l'événement d'arrêt n'est pas survenu lancer la temporisation, à toi de trouver quel évenement doit arrêter ton truc (un click sur la page, un doubleclick ...)
Merci pour ta suggestion comme celle de Sylvain.
La faille est que ni setTimeout() ni setInterval() bloque le script, qui continue son exécution comme si rien n'était: tout ce qu'ils font est de déclencher une autre action après l'intervalle choisie.
Et cela n'est pas le déroulement souhaité: - le script produit un résultat intermédiaire qu'il affiche. - il doit rester affiché jusqu'à ce que soit 1. un laps de temps choisi par l'utilisateur a écoulé 2. le dernier clique sur "Continuer" 3. ou éventuellement il appuie sur une touche - avant de calculer et afficher le prochain résultat.
C'est le mode de fonctionnement normal de milliers de programmes - le seul problème ici est l'environnement d'exécution: le comportement des navigateurs.
Ce que je ne veux certainement _pas_ est d'utiliser setInterval() pour obliger le pauvre utilisateur de cliquer sur "Attends encore..." toutes les cinq secondes afin d'éviter de voir disparaître ce qu'il est en train de regarder. En tout cas le seule différence serait d'agacer ce dernier: pendant l'intervalle définie le script devrait continuer à boucler (càd demander l'heure sans arrêt).
Amicalement CriCri
-- bitwyse [PGP KeyID 0xA79C8F2C] Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse mais aurait préféré ne pas la savoir. http://www.le-maquis.net
Salut
Michel_D a écrit :
Il faut combiner "setTimeout()" et "setInterval()".
En gros tous les les x interval si l'événement d'arrêt n'est pas
survenu lancer la temporisation, à toi de trouver quel évenement doit
arrêter ton truc (un click sur la page, un doubleclick ...)
Merci pour ta suggestion comme celle de Sylvain.
La faille est que ni setTimeout() ni setInterval() bloque le script, qui
continue son exécution comme si rien n'était: tout ce qu'ils font est
de déclencher une autre action après l'intervalle choisie.
Et cela n'est pas le déroulement souhaité:
- le script produit un résultat intermédiaire qu'il affiche.
- il doit rester affiché jusqu'à ce que soit
1. un laps de temps choisi par l'utilisateur a écoulé
2. le dernier clique sur "Continuer"
3. ou éventuellement il appuie sur une touche
- avant de calculer et afficher le prochain résultat.
C'est le mode de fonctionnement normal de milliers de programmes - le
seul problème ici est l'environnement d'exécution: le comportement des
navigateurs.
Ce que je ne veux certainement _pas_ est d'utiliser setInterval() pour
obliger le pauvre utilisateur de cliquer sur "Attends encore..." toutes
les cinq secondes afin d'éviter de voir disparaître ce qu'il est en
train de regarder.
En tout cas le seule différence serait d'agacer ce dernier: pendant
l'intervalle définie le script devrait continuer à boucler (càd demander
l'heure sans arrêt).
Amicalement
CriCri
--
bitwyse [PGP KeyID 0xA79C8F2C]
Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse
mais aurait préféré ne pas la savoir.
http://www.le-maquis.net
Il faut combiner "setTimeout()" et "setInterval()".
En gros tous les les x interval si l'événement d'arrêt n'est pas survenu lancer la temporisation, à toi de trouver quel évenement doit arrêter ton truc (un click sur la page, un doubleclick ...)
Merci pour ta suggestion comme celle de Sylvain.
La faille est que ni setTimeout() ni setInterval() bloque le script, qui continue son exécution comme si rien n'était: tout ce qu'ils font est de déclencher une autre action après l'intervalle choisie.
Et cela n'est pas le déroulement souhaité: - le script produit un résultat intermédiaire qu'il affiche. - il doit rester affiché jusqu'à ce que soit 1. un laps de temps choisi par l'utilisateur a écoulé 2. le dernier clique sur "Continuer" 3. ou éventuellement il appuie sur une touche - avant de calculer et afficher le prochain résultat.
C'est le mode de fonctionnement normal de milliers de programmes - le seul problème ici est l'environnement d'exécution: le comportement des navigateurs.
Ce que je ne veux certainement _pas_ est d'utiliser setInterval() pour obliger le pauvre utilisateur de cliquer sur "Attends encore..." toutes les cinq secondes afin d'éviter de voir disparaître ce qu'il est en train de regarder. En tout cas le seule différence serait d'agacer ce dernier: pendant l'intervalle définie le script devrait continuer à boucler (càd demander l'heure sans arrêt).
Amicalement CriCri
-- bitwyse [PGP KeyID 0xA79C8F2C] Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse mais aurait préféré ne pas la savoir. http://www.le-maquis.net
Michel_D
re,
J'avais un truc en javascript (résolution d'une grille sudoku) avec paramêtrage de la durée d'affichage des coups intermédiaire et j'avais utilisé une combinaison de "setTimeout()" et "setInterval()".
"CriCri" a écrit dans le message de news:483bdf82$0$837$
Salut
Michel_D a écrit : > > Il faut combiner "setTimeout()" et "setInterval()". > > En gros tous les les x interval si l'événement d'arrêt n'est pas > survenu lancer la temporisation, à toi de trouver quel évenement doit > arrêter ton truc (un click sur la page, un doubleclick ...)
Merci pour ta suggestion comme celle de Sylvain.
La faille est que ni setTimeout() ni setInterval() bloque le script, qui continue son exécution comme si rien n'était: tout ce qu'ils font est de déclencher une autre action après l'intervalle choisie.
Et cela n'est pas le déroulement souhaité: - le script produit un résultat intermédiaire qu'il affiche. - il doit rester affiché jusqu'à ce que soit 1. un laps de temps choisi par l'utilisateur a écoulé 2. le dernier clique sur "Continuer" 3. ou éventuellement il appuie sur une touche - avant de calculer et afficher le prochain résultat.
C'est le mode de fonctionnement normal de milliers de programmes - le seul problème ici est l'environnement d'exécution: le comportement des navigateurs.
Ce que je ne veux certainement _pas_ est d'utiliser setInterval() pour obliger le pauvre utilisateur de cliquer sur "Attends encore..." toutes les cinq secondes afin d'éviter de voir disparaître ce qu'il est en train de regarder. En tout cas le seule différence serait d'agacer ce dernier: pendant l'intervalle définie le script devrait continuer à boucler (càd demander l'heure sans arrêt).
Non, c'est l'action de l'utilisateur qui arrête la tempo, s'il ne fait rien la tempo se poursuit d'ou le setInterval() pour le test de l'action de l'utilisateur.
PS:Tu pourrais même incorporer une tempo maximum (nombre de setInterval() effectué).
re,
J'avais un truc en javascript (résolution d'une grille sudoku) avec
paramêtrage de la durée d'affichage des coups intermédiaire et
j'avais utilisé une combinaison de "setTimeout()" et "setInterval()".
"CriCri" <bitwyse@leTIRETmaquis.net> a écrit dans le message de news:483bdf82$0$837$ba4acef3@news.orange.fr...
Salut
Michel_D a écrit :
>
> Il faut combiner "setTimeout()" et "setInterval()".
>
> En gros tous les les x interval si l'événement d'arrêt n'est pas
> survenu lancer la temporisation, à toi de trouver quel évenement doit
> arrêter ton truc (un click sur la page, un doubleclick ...)
Merci pour ta suggestion comme celle de Sylvain.
La faille est que ni setTimeout() ni setInterval() bloque le script, qui
continue son exécution comme si rien n'était: tout ce qu'ils font est
de déclencher une autre action après l'intervalle choisie.
Et cela n'est pas le déroulement souhaité:
- le script produit un résultat intermédiaire qu'il affiche.
- il doit rester affiché jusqu'à ce que soit
1. un laps de temps choisi par l'utilisateur a écoulé
2. le dernier clique sur "Continuer"
3. ou éventuellement il appuie sur une touche
- avant de calculer et afficher le prochain résultat.
C'est le mode de fonctionnement normal de milliers de programmes - le
seul problème ici est l'environnement d'exécution: le comportement des
navigateurs.
Ce que je ne veux certainement _pas_ est d'utiliser setInterval() pour
obliger le pauvre utilisateur de cliquer sur "Attends encore..." toutes
les cinq secondes afin d'éviter de voir disparaître ce qu'il est en
train de regarder.
En tout cas le seule différence serait d'agacer ce dernier: pendant
l'intervalle définie le script devrait continuer à boucler (càd demander
l'heure sans arrêt).
Non, c'est l'action de l'utilisateur qui arrête la tempo, s'il ne fait rien la
tempo se poursuit d'ou le setInterval() pour le test de l'action de
l'utilisateur.
PS:Tu pourrais même incorporer une tempo maximum (nombre de
setInterval() effectué).
J'avais un truc en javascript (résolution d'une grille sudoku) avec paramêtrage de la durée d'affichage des coups intermédiaire et j'avais utilisé une combinaison de "setTimeout()" et "setInterval()".
"CriCri" a écrit dans le message de news:483bdf82$0$837$
Salut
Michel_D a écrit : > > Il faut combiner "setTimeout()" et "setInterval()". > > En gros tous les les x interval si l'événement d'arrêt n'est pas > survenu lancer la temporisation, à toi de trouver quel évenement doit > arrêter ton truc (un click sur la page, un doubleclick ...)
Merci pour ta suggestion comme celle de Sylvain.
La faille est que ni setTimeout() ni setInterval() bloque le script, qui continue son exécution comme si rien n'était: tout ce qu'ils font est de déclencher une autre action après l'intervalle choisie.
Et cela n'est pas le déroulement souhaité: - le script produit un résultat intermédiaire qu'il affiche. - il doit rester affiché jusqu'à ce que soit 1. un laps de temps choisi par l'utilisateur a écoulé 2. le dernier clique sur "Continuer" 3. ou éventuellement il appuie sur une touche - avant de calculer et afficher le prochain résultat.
C'est le mode de fonctionnement normal de milliers de programmes - le seul problème ici est l'environnement d'exécution: le comportement des navigateurs.
Ce que je ne veux certainement _pas_ est d'utiliser setInterval() pour obliger le pauvre utilisateur de cliquer sur "Attends encore..." toutes les cinq secondes afin d'éviter de voir disparaître ce qu'il est en train de regarder. En tout cas le seule différence serait d'agacer ce dernier: pendant l'intervalle définie le script devrait continuer à boucler (càd demander l'heure sans arrêt).
Non, c'est l'action de l'utilisateur qui arrête la tempo, s'il ne fait rien la tempo se poursuit d'ou le setInterval() pour le test de l'action de l'utilisateur.
PS:Tu pourrais même incorporer une tempo maximum (nombre de setInterval() effectué).
Sylvain SF
CriCri wrote on 27/05/2008 12:16:
La faille est que ni setTimeout() ni setInterval() bloque le script,
ils ne bloquent pas et c'est ce que l'on attend d'eux
qui continue son exécution comme si rien n'était: tout ce qu'ils font est de déclencher une autre action après l'intervalle choisie.
quelle exécution serait continuée ??
ta description est assez succinte mais imaginons qu'il existe un script pour calculer "ce qui est affiché", actuellement cette tache est dans une boucle "tant que l'utilisateur en redemande" et contient une pause, il suffit juste de couper ça en
a) une routine d'affichage:
function affiche(){ ... }
b) un mini-scheduler:
var delaiUtilisateur = ??; var refreshEvent = null;
function afficheEtape(){ ... affiche(); refreshEvent = setTimeout(afficheEtape, delaiUtilisateur); }
à la sortie de 'affiche' l'exécution de affiche est arrétée. à la sortie de 'afficheEtape' l'exécution de afficheEtape est arrétée. seul un process du navigateur tourne (sans aucun effet nuisible) pour réinvoquer afficheEtape dans qlq temps.
> Et cela n'est pas le déroulement souhaité:
- le script produit un résultat intermédiaire qu'il affiche.
affiche()
- il doit rester affiché jusqu'à ce que soit 1. un laps de temps choisi par l'utilisateur a écoulé
c'est le but de setTimeout(afficheEtape, delaiUtilisateur);
2. le dernier clique sur "Continuer"
sur le handler associé, tuer l'event refreshEvent
3. ou éventuellement il appuie sur une touche
traiter dans levent handler concerné.
- avant de calculer et afficher le prochain résultat.
ce que fait le rappel à afficheEtape qui commence par affiche
C'est le mode de fonctionnement normal de milliers de programmes
et autant n'utilise pour cela un boucle bloquante - enfin pas depuis plus de 10 ans et la génération de la programmation évènementielle.
seul problème ici est l'environnement d'exécution: le comportement des navigateurs.
ailleurs aussi ton approche créé des problèmes (charge CPU inutile)
Sylvain.
CriCri wrote on 27/05/2008 12:16:
La faille est que ni setTimeout() ni setInterval() bloque le script,
ils ne bloquent pas et c'est ce que l'on attend d'eux
qui continue son exécution comme si rien n'était: tout ce qu'ils font
est de déclencher une autre action après l'intervalle choisie.
quelle exécution serait continuée ??
ta description est assez succinte mais imaginons qu'il existe
un script pour calculer "ce qui est affiché", actuellement
cette tache est dans une boucle "tant que l'utilisateur en
redemande" et contient une pause, il suffit juste de couper
ça en
a) une routine d'affichage:
function affiche(){
...
}
b) un mini-scheduler:
var delaiUtilisateur = ??;
var refreshEvent = null;
function afficheEtape(){
...
affiche();
refreshEvent = setTimeout(afficheEtape, delaiUtilisateur);
}
à la sortie de 'affiche' l'exécution de affiche est arrétée.
à la sortie de 'afficheEtape' l'exécution de afficheEtape est arrétée.
seul un process du navigateur tourne (sans aucun effet nuisible) pour
réinvoquer afficheEtape dans qlq temps.
> Et cela n'est pas le déroulement souhaité:
- le script produit un résultat intermédiaire qu'il affiche.
affiche()
- il doit rester affiché jusqu'à ce que soit
1. un laps de temps choisi par l'utilisateur a écoulé
c'est le but de setTimeout(afficheEtape, delaiUtilisateur);
2. le dernier clique sur "Continuer"
sur le handler associé, tuer l'event refreshEvent
3. ou éventuellement il appuie sur une touche
traiter dans levent handler concerné.
- avant de calculer et afficher le prochain résultat.
ce que fait le rappel à afficheEtape qui commence par affiche
C'est le mode de fonctionnement normal de milliers de programmes
et autant n'utilise pour cela un boucle bloquante - enfin pas depuis
plus de 10 ans et la génération de la programmation évènementielle.
seul problème ici est l'environnement d'exécution: le comportement des
navigateurs.
ailleurs aussi ton approche créé des problèmes (charge CPU inutile)
La faille est que ni setTimeout() ni setInterval() bloque le script,
ils ne bloquent pas et c'est ce que l'on attend d'eux
qui continue son exécution comme si rien n'était: tout ce qu'ils font est de déclencher une autre action après l'intervalle choisie.
quelle exécution serait continuée ??
ta description est assez succinte mais imaginons qu'il existe un script pour calculer "ce qui est affiché", actuellement cette tache est dans une boucle "tant que l'utilisateur en redemande" et contient une pause, il suffit juste de couper ça en
a) une routine d'affichage:
function affiche(){ ... }
b) un mini-scheduler:
var delaiUtilisateur = ??; var refreshEvent = null;
function afficheEtape(){ ... affiche(); refreshEvent = setTimeout(afficheEtape, delaiUtilisateur); }
à la sortie de 'affiche' l'exécution de affiche est arrétée. à la sortie de 'afficheEtape' l'exécution de afficheEtape est arrétée. seul un process du navigateur tourne (sans aucun effet nuisible) pour réinvoquer afficheEtape dans qlq temps.
> Et cela n'est pas le déroulement souhaité:
- le script produit un résultat intermédiaire qu'il affiche.
affiche()
- il doit rester affiché jusqu'à ce que soit 1. un laps de temps choisi par l'utilisateur a écoulé
c'est le but de setTimeout(afficheEtape, delaiUtilisateur);
2. le dernier clique sur "Continuer"
sur le handler associé, tuer l'event refreshEvent
3. ou éventuellement il appuie sur une touche
traiter dans levent handler concerné.
- avant de calculer et afficher le prochain résultat.
ce que fait le rappel à afficheEtape qui commence par affiche
C'est le mode de fonctionnement normal de milliers de programmes
et autant n'utilise pour cela un boucle bloquante - enfin pas depuis plus de 10 ans et la génération de la programmation évènementielle.
seul problème ici est l'environnement d'exécution: le comportement des navigateurs.
ailleurs aussi ton approche créé des problèmes (charge CPU inutile)
Sylvain.
Sylvain SF
CriCri wrote on 27/05/2008 12:13:
Merci pour ta réponse - enfin à la question posée (et non pas d'autres!).
si tu penses que compter le nombre de statements JS exécutés - dépendent de la freq. du CPU - et que forcer chaque visiteur à modifier sa BdR est la solution à ton problème, c'est - je le crains - que tu ne te poses pas les bonnes questions.
donc merci pour ceux qui avaient fait l'effort de dépasser la mauvaise question posée pour apporter une aide utile.
Sylvain.
CriCri wrote on 27/05/2008 12:13:
Merci pour ta réponse - enfin à la question posée (et non pas d'autres!).
si tu penses que compter le nombre de statements JS exécutés - dépendent
de la freq. du CPU - et que forcer chaque visiteur à modifier sa BdR
est la solution à ton problème, c'est - je le crains - que tu ne te
poses pas les bonnes questions.
donc merci pour ceux qui avaient fait l'effort de dépasser la mauvaise
question posée pour apporter une aide utile.
Merci pour ta réponse - enfin à la question posée (et non pas d'autres!).
si tu penses que compter le nombre de statements JS exécutés - dépendent de la freq. du CPU - et que forcer chaque visiteur à modifier sa BdR est la solution à ton problème, c'est - je le crains - que tu ne te poses pas les bonnes questions.
donc merci pour ceux qui avaient fait l'effort de dépasser la mauvaise question posée pour apporter une aide utile.
