Pb avec ON_CHANGE

J'utilise régulièrement les routines d'évènement, mais je reste bloqué sur un problème avec ON_CHANGE avec un objet EDIT. J'ai réduit le code au minimum pour mettre le problème en évidence. Le voici:

Code:

label change

edit 10 : top 10,10 : left 10,10
' on_change 10,change

text 10,"xxx"
text 10,"yyy"

end

change:
return

A la fin de l'exécution, mon édit affiche "yyy" - tout va bien.

Maintenant, enlevons l'apostrophe devant la ligne 4 pour activer ON_CHANGE. Et là, la commande text 10,"xxx" s'effectue bien, mais je ne vois plus le résultat de text 10,"yyy". Pourtant, la routine change ne fait littéralement rien et est donc très rapide. Pourquoi mon programme ne semble pas effectuer la ligne 7 ?

C'est sûrement lié au fait que lorsqu'on fait afficher quelque chose par le programme
sur un objet sur lequel est affecté un on_change, cela change l'état de l'objet,
donc le on_change s'applique. D'ailleurs, si tu mets ton on_change après les 2 affichages,
cela règle le problème, mais cela n'explique pas tout, effectivement.
Cela n'explique pas pourquoi le yyy disparaît (ou n'apparaît pas) !
Et puis, j'ai essayé d'une autre manière (voir pg ci-dessous) et là, ça plante carrément :

Code:

label change
memo 10 : top 10,10 : left 10,10
on_change 10,change
item_add 10,"xxx"
item_add 10,"yyy"
end
change:
item_add 10,"+++"
return

Il doit effectivement y avoir sûrement un bug.

Dans ce cas, le plantage s'explique par le fait que tu as provoqué une boucle infinie:
le premier item_add génère l'évènement on_change. Dans cet évènement, tu en déclenches un nouveau avec "+++" qui à son tour, génère un évènement et ainsi de suite. On n'en sort jamais.

Revenons à mon premier exemple. J'ai tenté de temporiser entre les deux commandes text 10,... . Bien sûr, je ne peux pas utiliser WAIT car dans ce cas, même les évènements sont suspendus. J'ai fait une boucle de mille fois DISPLAY, entre les deux commandes TEXT. Pourtant, la seconde n'est jamais effectuée. Mystère.

Aparemment, le évenement "on_click" cause la machine de quitter tout se qui suit, comme si il y avait un "end", malgré le "return".
Voir ce bout de code: les messages ne sont pas du tout affichés; il faut donc activer le évenement "on_click" le plus tard possible.

Code:

label change

edit 10 : top 10,10 : left 10,10
on_change 10,change
 text 10,"xxx"
 message "1"
 text 10,"yyy"
 message "2"
end

change:
return

Salut Klaus,
Je sais c'est l'heure de l'apéro, mais là je suis étonné!
Comment tu peux dire cela?
Tu créais Edit, et tu mets de suite on_change, puis après tu mets du texte. C'est d'ailleurs ce que j'ai expliqué à exdragon, le texte est modifié juste après s'en avoir fini de mettre en place le restant.
Tu crée un événement dès le départ, et là Panoramic devient évennementiel!
Personnellement pour moi il y a un bug, dans le sens où le reste est ignoré, de la même manière qu'un timer.
Bon Panoramic a toujours fonctionné comme cela. J'ai lu toute la conversation de Jack, mais il y a des choses, quand on programme de multiples choses (je sais chose, je me répète), on voit qu'il y a de temps en temps des problèmes. Et les choses ne sont pas simples à expliquer, lorsqu'on est en face d'un programme de 1000 lignes ou plus.
Est-ce qu'il est normal, qu'un événement arrête la lecture d'un code, sans le reprendre ensuite?
Salut lodchjo, on se croise

Dans ton programme Klaus, le label change ne contient rien, donc il ne se passe rien.
Text 10 est renseigné avant end, donc c'est la dernière ligne de code qui est lu.

Par contre ce qui est curieux c'est qu'avec le programme de JJN4 on a l'équivalant d'un terminate.

A+

Edit: message écrit avant intervention de Cosmos

Mais il y a bien un os

Code:

edit 10 : top 10,10 : left 10,10
label change

on_change 10,change

text 10,"xxx"
text 10,"yyy"

end

change:
caption 0,text$(10)
return

Dans cet exemple le caption de 0 ne devrait pas afficher XXX tant qu'on a pas tapé un caractère dans l'édit

Bien sûr que le programme "change" ne fait rien ! Le problème, c'est que la commande etxt 10,"yyy" ne s'exécute pas dès que on_change 10,change est activé, mais marche bien tant que cette ligne n'est pas activée.

Si je fais ceci:

Code:

label change, clic

button 1 : top 1,40 : left 1,10 : caption 1,"Lancer"
on_click 1,clic

edit 10 : top 10,10 : left 10,10
on_change 10,change

end

change:
return

clic:
text 10,"xxx"
text 10,"yyy"
return

je constate que tout marche ! La comande text 10,"yyy" est bien exécutée, alors qu'elle ne l'est pas dans le premier programme que j'ai posté, dès qu'on active la ligne on_change 10,change.

J'ai l'impression que contrairement à ce que dit Jack, au niveau de la gestion des évènements, ce n'est pas la même gestion avant ou après la commande END. Il est vrai qu'avant le END, les évènements sont actifs, mais il ne semble pas évident de les utiliser de la même manière qu'après le END. La preuve - si l'on met en parallèle le fonctionnement des deux versions que j'ai postées, la seconde fonctione, mais pas la première (enlever l'apostrophe devant la ligne 4).

@Jean-Claude: nos messages se sont croisés.

Si, il devrait afficher "xxx" et le remplacer immédiatement par "yyy". La commande TEXT doit s'exécuter normalement, et c'est indépendant que quelque chose qu'on frappe dans le champ. Chaque commande TEXT "change" le contenu de l'EDIT, et de ce fait déclenche l'évènement ON_CHANGE.

Ceci est un vieux problème. J'en ai parlé il y a bien longtemps. Tout ce que tu dis est vrai.

Je suis seulement surpris que tu ne le constates qu'aujourd'hui. Combien de fois il a été dit qu'il fallait mettre le ON_CHANGE vers le END, comme ON_TIMER ou TIMER_ON. Cela n'a vraiment pas soulevé la foule. Chaque fois que je dois modifier un objet avec cette fonction, je fais OFF_CHANGE. Et je trouve dommage que ON_CHANGE n'est pas son pendant comme TIMER_ON N, qui ne précise pas le label. Je pense que CHANGE_ON serait bien pratique. Il faut se rappeler du branchement pour réactiver le ON_CHANGE.

Tu as raison, Cosmos70, mais ce n'était pas le but le mon intervention.

Comme toi, je mets toujours les ON_xxx vers la fin avant le END, et je ne compte pas sur les évènements avant. Pour moi, tout doit se jouer en interactif, APRES le END.

Mais j'interviens a près les dires de Jack, sur un autre post, et son nouveau tuto: il dit que Panoramic fonctionnne pareil, avant ou après le END, je END ne servant qu'à stopper l'exécution linéaire afin de ne pas tomber dans l'exécution des sous-programmes qui suivent. Et c'est là que je ne suis pas d'accord.

Même si théoriquement, Panoramic devrait fonctionner comme ça, mes deux petits bouts de code montrent qu'il n'en est rien, et comme toi, je sais que beaucoup d'entre nous ont déjà eu ce genre d'expérience, concernant la différence de fonctionnement avant et après le END. J'ai ouvert un nouveau sujet dans "A l'aide" pour cela, car je ne voulais pas polluer l'autre post, et en l'état, je ne voulais pas non plus signaler cela comme un "bug", même si cela y ressemble beaucoup.

Vu que Jack s'est donné la peine de clarifier le fonctionnement avant et après le END, en ajoutant même un tuto, je pense qu'il serait utilile qu'il regarde mes deux morceaux de code pour séparer le faux du vrai. Pour la simplicité, voici à nouveau les deux codes:
1. Celui qui ne marche pas (et qui marche en remettant un apostrophe devant la ligne 4):

Code:

label change

edit 10 : top 10,10 : left 10,10
on_change 10,change

text 10,"xxx"
text 10,"yyy"

end

change:
return

et celui qui marche:

Code:

label change, clic

button 1 : top 1,40 : left 1,10 : caption 1,"Lancer"
on_click 1,clic

edit 10 : top 10,10 : left 10,10
on_change 10,change

end

change:
return

clic:
text 10,"xxx"
text 10,"yyy"
return

Franchement, entre les deux, ce qui change, c'est que dans le premier cas, les deux commandes TEXT sont émises avant le END, et dans le second cas, après le END.

Je te comprends. Le problème existe depuis longtemps. Je me souviens des difficultés que j'ai eues, lorsque j'ai voulu faire ma boite de stop par exemple avec les événements. Il faut que ce soit toi qui le dises. Je n'ai aucun poids pour le faire comprendre.

Je répète que le END n'a rien à voir avec la gestion des événements, que les événements sont actifs dès leur déclaration (ON_CLICK, ON_CHANGE,...)

Je pense que tu as mis le doigt sur un vrai problème. Il semble qu'après la ligne

Code:

text 10,"xxx"

le traitement d'événement CHANGE s'effectue bien, car il s'agit effectivement d'un changement de l'EDIT, mais que l'éxecution ne revienne jamais à la ligne suivante, c'est à dire

Code:

text 10,"yyy"

J'en suis étonné. Je pense que le bug s'est produit lors du codage de la file d'attente des événements.
Ce problème et sa résolution sont prioritaires.

Ah, merci Jack ! Je n'était pas vraiment sûr de moi, mais tu confirmes mon intuition, et cela me rassure car je commençais à douter de mes capacités d'analyse.

@klaus

Je te remercie car tu m'a fait découvrir une erreur d’interprétation, de ma part, concernant l'usage de ON_CHANGE. Je pensais qu'il fallait absolument une frappe au clavier dans l'édit pour déclencher l’évènement.
Je comprend, maintenant, les galères que j'ai dans certain programme.

Vraiment, un grand merci, je vais moins galérer à l'avenir.

A+

Etonnant que cela ne marche pas car dans mon programme analyse de fichier log je l'utilise sans problème...
Maintenant je n'ai pas encore vérifier avec la dernière version de Panoramic...

Tout d'abord, la correction de ce bug est ma priorité car on ne peut actuellement pas utiliser les événements comme on le devrait.

Après une première analyse, il se trouve que lors de l'exécution de la ligne

Code:

text 10,"xxx"

le traitement de l'événement "CHANGE" sur l'EDIT se passe convenablement, mais s'effectue la plupart du temps de façon immédiate alors que le traitement de cette ligne n'est pas complètement terminé par PANORAMIC, et en particulier, des pointeurs internes sur la ligne suivante du source n'ont pas pu être positionnés.

Lorsque l'événement "CHANGE" a été traité, il n'y a pas de reprise à la ligne suivante car PANORAMIC ne trouve pas ses pointeurs sur la ligne suivante du source, et le traitement du programme principal s'arrête.
Tout se passe en fait comme si un "END" avait été exécuté après cette ligne. (END=arrêt de l'exécution du programme principal)

C'est seulement aujourd'hui que je comprends la méfiance sur la programmation événementielle et toute la confusion qu'il y a eu sur le "END" qui démarrait le traitement des événements, et pourquoi il y a eu des conseils de mettre les commandes d'activation d'événements ON_XXX juste avant le END.

Très intéressante, ton analyse.

Mais alors, ça pose une autre question: pourquoi, dans mon deuxième exemple (celui où les deux lignes "text 10,..." sont déclenchées dans l'évènement in_click d'un bouton), on n'a pas le même phénomène ? Une routine évènement serait-elle ininterruptible par un autre évènement ?

Et dans ce cas, dans la partie avant le END, pourrait-on imaginer des commandes EVENTS_SUSPEND et EVENTS_RESTART permettant de mettre les évènements entre EVENTS_SUSPEND et EVENTS_RESTART dans une file d'attente sans les exécuter, et de relancer l'exécution de ces évènements par la commande EVENTS_RESTART ?

Dans ton deuxième exemple:

Code:

label change, clic

button 1 : top 1,40 : left 1,10 : caption 1,"Lancer"
on_click 1,clic

edit 10 : top 10,10 : left 10,10
on_change 10,change

end

change:
return

clic:
text 10,"xxx"
text 10,"yyy"
return

cela fonctionne correctement car quand tu cliques sur le bouton, il y a belle lurette que le programme principal s'est terminé. On est alors en purement événementiel: il n'y a aucun traitement d'événement qui vient perturber le fonctionnement du programme principal, puis que celui-ci est fini.

On est ici dans un autre cas de figure que celui qui ne fonctionne pas. Il n'y a ici plus aucun traitement en cours, les traitements d'événements s'exécutent mais ne peuvent en aucun cas interférer les uns avec les autres car lorsqu'un événement survient pendant le traitement d'un autre événement, il est placé en file d'attente et s'effectuera après.

Nous sommes dans le cas que tout le monde a appelé "après le END" et dans ce cas, les traitements d'événements ne s'interrompent pas, mais s'effectuent les uns après les autres dans l'ordre d'arrivée. Et tout se passe bien. (Les savants, dont je ne fais pas partie, appellent cela "un mode de traitement non-préhemptif des événements")

Le cas qui ne marche pas, c'est quand un événement arrive alors que le programme principal n'est pas terminé. Je pense qu'on ne voit ce cas que lorsque le programme principal déclenche lui-même un événement comme l'écriture dans un EDIT, qui provoque un événement "CHANGE".

Quand tout sera corrigé, je ferai un tutoriel.

J'en tire la conclusion, et là encore si j'ai bien compris ce que je viens de lire, que tout les codes que j'ai fait contenant ON_CHANGE ne sont pas à modifier car j'ai placé ces on_change après end (donc là l'exécution du programme principal est terminé, il n'y a pas d'incidence)

Si quelqu'un (Jack a du boulot) peut me confirmer...

A+

Effectivement, ta conclusion est correcte, et mon deuxième exemple le démontre.

Merci Klaus A+

Ce BUG est résolu.
Il me reste à faire tous les tests sur les événements (sans doute ce week-end) pour m'assurer que tout est correct et je diffuse une version instantannée avec la correction (avant dimanche soir au plus tard).

Ca, c'est de la réactivité ! Merci d'être intervenu si rapidement et si efficacement !

C'est vrai, ça c'est de la réaction, c'est vraiment cool d'avoir un concepteur comme ça dans un forum

(Mon clavier saute des lettres, désolé si j'édite souvent...)