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+