Salut tout le monde.
Vous avez probablement tous raison, mais je préfère insister sur ce qui suit :
Si dans mon programme je dois gérer un click sur un bouton, j’aurais le choix de programmer ça, soit en optant pour une programmation séquentielle, procédurale, structurée ou tout ce qu’on veut, soit en optant pour une programmation événementielle.
Je peux considérer le click sur un bouton comme une simple action et user d’astuces ou de trucs pour essayer de m’en sortir.
Et pour peu que le code ne soit pas (très) simple, je dois m’attendre à des dysfonctionnements de mon programme.
Cette méthode n’est donc pas la bonne selon mes compétences.
La solution (sage, sûre et recommandée, toujours selon mes compétences) consiste à opter pour une programmation événementielle.
Pourquoi m’en priver, alors que Panoramic le permet ?
Pour gérer un événement, Panoramic nous propose un ensemble de commandes
ON_CHANGE, ON_CLICK, ON_CLOSE, ON_TIMER, etc.Ces commandes signifient qu’à chaque fois que l’événement survient (à n’importe quel instant ou même jamais), le programme doit se rompre momentanément pour aller exécuter le sous-programme indiqué et revenir au point de rupture quand il rencontre la commande RETURN.
Cela signifie que le système entre dans une boucle pour scruter l’arrivée d’un éventuel événement et agir en conséquence.
Klaus a très bien expliqué ce qu’est une fonction et pourquoi on ne peut pas affecter une valeur à une fonction : mathématiquement, ça n’a pas de sens !
Pour revenir au dernier code de Jean Claude, je dirai :
La définition de l’événement se fait dans une procédure SUB init()
Quand l’événement survient (click sur le bouton 1 ou 2), le système doit sauvegarder sur la pile son environnement de travail, se brancher sur le sous-programme
CLIC : qu’il exécutera jusqu’à l’instruction RETURN qui lui ordonne d’aller récupérer de la pile son environnement de travail pour continuer son exécution.
Or le sous-programme de l’événement en question, fait lui-même un appel à la procédure SUB init() avant de se terminer.
On est devant une procédure qui appelle un sous-programme qui appelle une procédure qui appelle un sous-programme qui appelle …
C'est une récursivité incontrôlée.
Et on se demande pourquoi ça déclenche une avalanche d’erreurs !.
Bon, j’ai donné mon point de vue qui n’engage que moi.
EDIT
- jean Claude a écrit:
- Bref, çà pose quand même un problème: Comment fait t'on pour réinitialiser la valeur de CLICKED(N) à zéro puisque OFF_CLICK N ne le fait pas
On ne peut donc tester le bouton qu'une seule fois ????
CLICKED(N) est une fonction.
Elle vaut une certaine valeur (soit 0, soit 1) et parler de la réinitialiser n’a pas de sens.
Ce n’est pas vrai que l’on ne peut tester le bouton qu’une seule fois : on peut le tester autant de fois que l’on veut ; la fonction retournera toujours 1 si on a déjà cliqué sur le bouton au moins une fois durant le déroulement du programme, sinon elle retournera 0
Pensez à la fonction
FILE_EXISTS(F$) qui vaut 1 si le fichier F$ existe et 0 sinon.
CLICKED(N) et FILE_EXISTS(F$) sont du même type : le type fonction.
Si on teste l’existence d’un fichier par FILE_EXISTS(F$) et si cette fonction retourne 1, cela veut dire que le fichier existe.
Peut-on parler de réinitialiser la valeur de FILE_EXISTS(F$) à zéro ? Certainement pas : le fichier existe et c’est tout.
Parler de réinitialiser la fonction n’a aucun sens.
Accueil 
Calendrier
