Prochaine version

La prochaine version aura les fonctionnalités suivantes.

1 - 2 nouvelles fonctions:
SPRITE_X_POSITION(N) : retourne la position en X du SPRITE numéro n
SPRITE_Y_POSITION(N) : retourne la position en Y du SPRITE numéro n

2 - 4 nouvelles variables système:
NUMBER_CLICKED dont la valeur est le numéro d'objet cliqué
NUMBER_CHANGED dont la valeur est le numéro d'objet changé
NUMBER_KEY_DOWN dont la valeur est le numéro d'objet sur lequel une touche a été enfoncée
NUMBER_KEY_UP dont la valeur est le numéro d'objet sur lequel une touche a été relachée

3 - la commande SPRITE_TARGET_IS N conformément à la documentation

4 - le bug corrigé sur SELECT / CASE / END_SELECT

5 - un objet TIMER et ses commandes associées:
TIMER N
ON_TIMER N,LABEL
TIMER_INTERVAL T
TIMER_ON N
TIMER_OFF N

6 - Pour éviter un mélange incompatible de programmation procédurale et de programmation événementielle:
les commandes INPUT, WAIT et EXECUTE_WAIT seront interdites (leur exécution provoquera une erreur) à partir du moment où une déclaration d'événement aura été exécutée: ON_TIMER, ON_CLICK, ON_CHANGE, ON_KEY_DOWN, ON_KEY_UP

7 - inversement, les déclarations d'événement ON_TIMER, ON_CLICK, ON_CHANGE, ON_KEY_DOWN, ON_KEY_UP seront interdites (leur exécution provoquera une erreur) à partir du moment où une commande INPUT, WAIT ou EXECUTE_WAIT aura été exécutée

8 - pour éviter une "programmation spaghetti", je prévois l'interdiction d'un GOTO dans les 3 cas suivants:
- GOTO du programme principal (le programme qui est exécuté au démarrage et qui se termine par END) vers un sous-programme
- GOTO d'un sous-programme vers le programme principal
- GOTO d'un sous-programme vers un autre sous-programme

9 - de même, il y aura 3 types de LABELs:
- le type LABEL_GOTO servant aux commandes GOTO,
- le type LABEL_GOSUB servant aux commandes GOSUB,
- le type LABEL_EVENT servant aux traitements d'événements ON_TIMER, ON_CLICK, ON_CHANGE, ON_KEY_DOWN, ON_KEY_UP

10 - les 3 utilisations suivantes seront interdites (leur exécution provoquera une erreur):
- GOTO vers un LABEL qui n'est pas déclaré comme LABEL_GOTO
- GOSUB vers un LABEL qui n'est pas déclaré comme LABEL_GOSUB
- ON_TIMER, ON_CLICK, ON_CHANGE, ON_KEY_DOWN, ON_KEY_UP
contenant un LABEL qui n'est pas déclaré comme LABEL_EVENT

Longue vie à PANORAMIC.

moi je dit juste bravo !!!!

Vince

Citation :

Longue vie à PANORAMIC

Exactement, Jack a tout dit !

Encore...... encore ......encore..... plus s.v.p

N'étant pas chez moi pour 8 jours et pour ne pas sqwatter l'ordi de ma fille, je ne répondrais qu'a ce sujet.

Je dis bravo à Jack pour la solution qu'il apporte, au sujet du mélange de méthode de programmation, car çà façon de gérer le problème (j'ai failli dire contourner) est on ne peut plus démocratique. En effet, la facilité était de supprimer tout simplement la façon (nonmée procédurale), mais en fait il fait controler par Panoramic l'utilisation des 2 façons (procédurale et événementiel). Ce qui permettra à tous le monde d'y trouver son compte.

Bravo pour les fonctions TIMER qui manquait vraiment.
Et pour finir, j'ajoute que les 4 variables systèmes, concernant les N° d'objet, (NUMBER_....) vont nous donner la possibilité de concevoir nos codes de manière différente et plus facile.

Merci et Bravo pour ces nouveautés.

A+

PS: cela fait "pile poil" un an que je suis arrivé sur ce Forum et j'en suis satisfait.

J'aime bien la façon dont la situation de clarifie, avec cette façon de séparer clairement la partie "procédurale" de la partie "évènementielle", et de distinguer de façon tout aussi rigoureuse les sous-prgrammes "normaux" des sous-programmes "évènements". La conception d'un programme ensera simplifié, et il sera plus clair et lisible pour un tiers. Bravo !

L'apparition du timer, c'est super. Un vrai plus.

@ Jack: as-tu eu l'occasion de regarder le problème avec handle_canvas() que j'ai signalé, et est-ce que l'idée d'une fonction adr(x%()) pour passer l'adresse de la partie data d'un array de entiers est recevable ?

Vraiment génial

Je profite de cet emplacement recent pour demander à Jack de regarder dans
la dernière version les "mouse_x...... tout ce qui est mouse qui chez moi en tout cas ne font pas ce qu'ils sont sense faire.

je voulais palier au prochaine sortie par la recup de la position de la souris sur le scene2d mais impossible.

a moins que ce soit moi qui bug....
....ca c'est encore possible

Je lis ce forum après une journée d'absence et je ne m'attendais pas à des réponses aussi positives.
Je m'attendais au contraire à une levée de boucliers sur la proposition de créer 3 types de LABELS. En effet, cela provoquerait, le jour où ce serait appliqué, une chose qui n'est jamais arrivée: la non-compatibilité ascendante des sources.

Il n'y aura pas que cela qui provoquera la "non compatibilité ascendante des sources"
il y a aussi le fait qu'on mélange tous un peu d'événementiel et de programmation linéaire, histoire de compléter ce qui n'est pas encore possible en événementiel pur,
Et ça va tout changer pour les vieux programmes qu'on a.

Bon, mais si il n'y a pas moyen de faire autrement pour avoir des timer
ce qui sera une avancée considérable qui évitera d'avoir à risquer des cycles goto de type scabreux,
tant pis, on modifiera tous nos vieux programmes
un peu de travail, mais bon...
j'ai compté, j'en ai environ 300,
mais ça donnera l'occasion de faire du nettoyage,
j'ai plein de vieux essais qui sont bon pour la poubelle et qui restent là...

Merci pour la compréhension de tous.
Mais je ne pouvais pas sortir un TIMER qui exécute un sous-programme à intervalle régulier (c'est le principe d'un timer) dans un programme qui permettrait une suspension totale par un INPUT.

Ou encore, il est facile de comprendre qu'un TIMER se déclenchant par exemple 5 fois par seconde ne puisse pas contenir dans son traitement périodique une commande WAIT 20000 qui ferait à chaque fois une suspension de 20 secondes!

Et les message_input$(...
ça ne gênera pas ?

Cela fait deux jours que je recule mon intervention. Contrairement à la majorité, je n'applaudis pas à 100 pour 100 sur l'ensemble de ce qui se dit.
En ce qui concerne les fonctions timer; rien à dire sinon quelles sont la bien venue, et j'en remercie Jack.

En revanche concernant mes label_goto ou gosub, en réservant une place particulière à label_event qui peut-être à ses raisons, je ne suis pas d'accord. Si Jack a des problèmes pour avancer dans les commandes à venir, j'approuve sans restrictions sa volonté.

Dans le cas où le but est d'éviter une programmation spaghetti comme on le faisait à une certaine époque, je suis plus rétrissant. Je ne dis pas qu'il faut le faire, parce que cela est un foutu bordel (et je sais ce que je dis). Mais qu'appelle-t-on programme spaghetti ici?

Un exemple: dans mon programme d'éditeur de cellule, j'ai un sous-programme qui était terminé. En faisant un ou deux jours plus tard, à un moment j'ai eu besoin de faire une partie du programme précédent. J'aurai pu à ce moment là, dire je vais rajouter un autre sous programme, reprendre la partie du code qu'on veut en double, et faire un gosub; et aussi faire un gosub dans mon autre sous-programme. La solution plus simple que j'ai trouvé à été de faire (oh mon dieu! ) un goto à un label qui se branche directement à ce qui était déjà fait. Jusqu'à présent cela marchait merveilleusement bien et ne semblait pas poser de problème au basic (un simple jump). Là 3ème solution est de remplacer le goto par un gosub au label supplémentaire dans le premier sous-prog, qui fait qu'au retour, j'aurai du rajouter un autre label pour me brancher à la fin de la procédure et éviter les lignes qui suivait. Ce qui fait 1) gosub partie faite. 2) retour à la suite du gosub, 3)goto au return de la procédure en cour. Résultat: des allées et venues du "yoyo". Pour moi la solution que j'ai choisi est la plus élégante, j'ai simplement changé de return, et je ne pense pas que cela ait posé de problème pour dépiler la pile (si c'est bien comme cela ça se passe).

La question est: Pourquoi faire simple quand on peut faire compliqué?
Si le basic a bien fonctionné jusqu'à présent, et semble pas un handicap au basic, pourquoi vouloir mettre un blocage supplémentaire? Panoramic est bien codé mais j'avoue que souvent le contrôle est vraiment pointilleux. Un mid$() n'a aucune souplesse, tout comme right$, il faut à chaque fois la juste longueur de chaine pour ne pas faire de dépassement. Si vous programmez comme moi, vous savez que tout le long du programme, il faut tout contrôler. Je ne fais pas de reproche mais une constatation. Et maintenant on en rajoute. Si c'est utile: d'accord, dans le cas contraire, pourquoi? pour une logique brute en se disant que cela doit être comme cela et pas autrement! Je ne suis pas maso, et pourquoi me faire mal?

Maintenant parlons des label_goto et label_gosub. Déjà cela a pour but de m'interdire de faire à partir d'une procédure un goto à des lignes de programmes et sortir sur un autre return. Ok on vient de voir.

j'ai un programme (c'est du n'importe quoi, je montre un principe)

Code:

etiquette_1:
  suite%=suite%+1:if suite%=10 then goto etiquette 2
  variable=1
etiquette_2:
  variable=variable+1
  etc...
  etc...
return

Je veux initialiser la variable_1 à 1, donc je vais faire un gosub etiquette_1
Pourquoi vouloir m'interdire de faire goto etiquette_2? Je vais devoir rajouter une 3ème étiquette qui sera une étiquette de goto. Si c'est pour le fun, je trouve cela absurde. Dans le cas contraire et qu'il ait une bonne raison, là je m'incline. Après tout je ne sais pas comment est fait Panoramic?
si je ne veux pas initialiser variable et sauter "suite%", je vais faire un gosub etiquette_2. Il faut encore espérer qu'on a le droit d'avoir deux ou plus étiquette_label dans la même procédure, autrement où on va?

Si c'est pour éviter des erreurs de programmation, je pense que ce serait plus judicieux d'avoir un bon mode d'emploi au départ pour savoir ce qui est permis ou pas pour qu'il n'y ait pas de perturbation dans le programme.

Je vais faire la demande suivante, qui évidemment ne sera pas repris, et certainement pas commenté: ne serait-il pas possible d'avoir une instruction qui permettrait de stopper le programme pendant la phase de teste lorsqu'il y a blocage suite à une erreur,puis ensuite lorsque tout est ok, on rajouterai (je ne sais pas si event est le bon terme?) off_event_stop en début de programme pour stopper cette intrusion. Cela aurait pour fonction d'arrêter le programme lorsqu'il y a blocage avec par exemple Ctrl pause ou autre (qui a pour conséquence de ralentir le basic obligatoirement puisque cela oblige de faire un détour pour tester la volonté de sortir) encore que cette instruction n'est certainement nécessaire que lorsqu'il y a une boucle!. Une fois le programme au point, on rajoute l'instruction qui évite ce détour.

Cosmos passe son temps à critiquer, et je me fais une réputation qui ne me plait pas. Mais si personne ne pose les problèmes, il faut bien que je le fasse. C'est d'ailleurs une des raisons qui me dit que je dois restreindre ma présence ici.

Un dernière chose: Si le basic doit changer, peut-être devra t-on laisser en présence sur le forum les deux versions de basics, afin que les anciens programmes qui n'ont pas besoin de commandes supplémentaires et ne seront pas intégrés au basic, fonctionnent! Si ce cas de figure est envisagé, ne serait-il pas judicieux de faire une différence de couleur de forme par exemple pour savoir sur quel système on est?

Je ne doute pas un seul instant que toutes mes remarques comme d'habitude vont être retenues, vu que tout le monde ou presque approuve les nouveaux principes. Je me demande juste si toutes les transformations sont nécessaire. On avait un basic simple, il se complique!

Pour ce qui concerne le mélange de codage événementiel ou non, de toute façon je crois que j'ai maintenant une solution pour moi.

152Maintenant je vais essayer de faire voeux d'abstinence. Ne m'en veux pas Jack, je sais que tu fais pour le mieux.

@ cosmos70:
Cela fait plusieurs jours que je regarde comment coder les 3 types de labels (label_goto, label_gosub et label_event) de manière à minimiser le travail important que cela représente pour moi. Et je me passerai bien volontiers de ce surcroit de travail.

Cette modification va à l'encontre de l'un de mes principes: la compatibilité ascendante.
De plus, cela ne représente pas une faible partie des sources qui ne fonctionneront plus, mais presque la totalité des sources déjà écrits.
Chacun va devoir réécrire voire repenser la structure de ses sources. Moi-même, je vais devoir retoucher les centaines et les centaines de programmes de test de Panoramic: chaque mot clé est testé dans un source et dans toutes les conditions (par exemple, il y a autant de programmes de test de la commande TOP qu'il y a d'objets visibles).

Et pourquoi?
Pour faire en sorte que les gens qui ne programment pas de façon réfléchie et structurée aient moins de problèmes.

Comme tu le fais remarquer, la complexité va augmenter et on va perdre en simplicité d'utilisation. Ta remarque me touche beaucoup. La simplicité d'utilisation est un autre de mes grands principes dans la réalisation de ce logiciel.
Il vaut mieux un bon tutoriel plutôt que de perdre en souplesse et en simplicité.

Comme toi, je pense que j'interviens trop sur le forum et que je propose trop. J'écoute trop souvent tous les sons de cloche et cela donne l'impression qu'il n'y a pas de ligne directrice dans le développement puisque je réalise des demandes récentes alors que des demandes anciennes et fondées sont retardées.

Pour le moment, je ne ferai pas de bouleversement.
Je continue le codage de fonctionnalités manquantes et le débugage.
Cela ne va pas plaire, mais je vais laisser faire des GOTO là où il faudrait un GOSUB et tant pis.

Les 3 types de labels sont reportés aux calendes grecques à cause de tout cela: compatibilité ascendante profondément touchée, surcroit de travail de codage, complexité d'utilisation, faible impact.

Je vais aussi me faire plus rare sur le forum et je n'interviendrai que "dans les cas graves". Je vais regarder ta proposition d'instructions pour la mise au point.
Autrefois, il y avait TRACE_ON et TRACE_OFF. Ces instructions pourraient écrire le cheminement du programme dans un fichier texte (date, heure, numéro de ligne). Il pourrait y avoir une commande PAUSE qui afficherait le contenu d'une variable dans ne fenêtre et une touche RESUME sur la fenêtre pour reprendre l'exécution.

Merci pour ta réponse.
A mon touche celle-ci me touche beaucoup.

Il n'y a pas mieux pour programmer que de connaitre la ligne directrice du fondateur et suivre celle-ci pour que le résultat final aille avec le codage final du programme.

Si tu me dis que faire "ceci comme cela" gène le développement de mon logiciel, mon pose des problèmes pour coder, dit toi bien que je ne ferais pas. Si je connais à l'avance les problèmes que tu dois surmonter pour améliorer Panoramic, j'en tiendrais compte dans mon codage.

Ce qui est nécessaire de savoir, c'est de bien connaitre ce que tu veux à l'avance qui ne complique pas la tâche.

Si par contre (pour exemple) mettre un goto dans une autre procédure, qui récupérera le return (et dépilera je crois mais c'est toi qui peut le dire le gosub précédent) et ne gène pas le codage de Panoramic, pourquoi l'interdire (dans mon cas c'est plus direct, cela fait des instructions en moins, donc de la rapidité...).

Si tu pouvais ajouter un mode trace, qui permettent aux gens ne respectant pas la méthode, de comprendre leurs erreurs, peut-être que cela éviterait de faire des labels particuliers (dont tu seras obliger de contrôler à chaque appel si c'est le bon type de label qui correspond).

Je ne sais pas si tu as vu, mais n'ayant pas beaucoup de moyens à ma disposition, j'ai réussi à faire un mode trace avec un logiciel en intégrant des lignes d'appel entre chaque ligne d'un programme. Peut-être tu pourrais faire une chose similaire en mettant un coche à l'éditeur, et constituer un programme intermédiaire qui permettrait de suivre le programme.

Ce n'est que des suggestions, moi j'ai rien à dire ou imposer. Je me sers des outils qu'on me donnes, et tu donnes beaucoup.

Merci à toi.

C'est bien aussi mon avis, que plutôt que de bouleverser la philosophie de Panoramic ça ne serait pas plus mal de consolider l'existant, en particulier résoudre les bugs en attente, et mettre à jour le manuel pour toutes les nouvelles fonctions.
Pour le TRACE_ON/TRACE_OFF, c'est vrai que ça manque beaucoup, il y a parfois des erreurs sans numéro de ligne, ça part dans les décors sans qu'on sache pourquoi.
Quant à PAUSE/RESUME avec affichage de variable(s), c'est facile à faire avec les outils existants: MESSAGE.

Je crois que ce n'est pas plus mal de faire un peu une pause dans les fonctions nouvelles.

Bonjour,

J'interviens pour la première fois sur le forum... je suis un lecteur assidu de vos messages et pourtant, je ne suis pas utilisateur du langage !!!

Et oui... je suis un espion en fait... je suis aussi l'auteur d'un langage de programmation.

J'ai découvert ce langage il y a quelques années au moment je voulais démarrer un projet de création d'un langage : je voulais faire un BASIC des temps modernes... malheureusement pour moi... et heureusement pour vous, il y avait déjà Panoramic, du coup, je suis parti sur une autre voie que le BASIC.

Jack a réussi deux choses : créer un interpréteur puissant et riche, et une bonne communauté autour de lui !

C'est bien pour ça que j'interviens aujourd'hui en lisant ses derniers posts. Il faut continuer à répondre pour aider, donner la bonne parole (la bonne programmation . Car je le rejoins, l’utilisation des GOTO est à proscrire… même si elle est bien utile quand on débute.

Maintenant, pour ma part, la plus grosse évolution que devrait apporter Jack à son langage, c'est le nommage des variables ! Out les nombres ! Mais que l'on puisse les nommer avec du texte ! C'est très important pour comprendre le code des autres et son code : une bonne sémantique est importante pour écrire du code sain !

Bon courage pour la suite et bravo encore !!

Cpc

Merci de tes conseils.
Bon courage aussi.
Linotte est un excellent langage pédagogique.

Bienvenue cpc.
ça me rappelle Amstrad, même si j'ai encore le 464 dans le grenier.

Je dis bienvenue, et pourtant si il y a une certaine chose que je n'aime pas, ce sont les idées reçues.

Citation :

Car je le rejoins, l’utilisation des GOTO est à proscrire

Je suis majoritairement contre les goto. Heureusement est apparu (en laissant for/next de côté, que j'ai connu dès 81) repeat/until, while/wend ou end_while, dans d'autre langage do/loop. etc...

Pourtant vouloir systématiquement refuser l'emploi de goto quand cela est utile et pratique est une aberration pour moi. C'est où? à la faculté que les profs vous incultent cela. Lorsque la structure est correct, que le dépilement des gosub est respecté, et que cela ne ressemble à du codage spaghetti pourquoi diante le refuser? "oh non sacrilège, c'est interdit/ c'est pas bien/ c'est interdit/ tu sais pas programmer "ou je ne sais pas quoi. C'est pour faire plaisir à son prof? qui vous observe. Un goto est parfois bien pratique, et de temps en temps fait gagner du temps en codage ou en temps d'exécution.

Je n'aime pas qu'on interdise une chose, parce que quelqu'un a foutu une chose dans la tête d'une autre, que cela ne se fait pas.
Chaque langage a ses conceptions, le basic a les siennes. Normalement ce langage est réputée plus lent que les autres, et aujourd'hui cela reste à voir. J'ai essayé Python et je trouve plus lent que Panoramique. Un goto bien souvent diminue le nombre d'instructions, et chaque instruction en moins est un gain de temps en temps machine (en principe seulement vu, chacune fait des choses plus ou moins complexe).

Je suis certain qu'on va aller à l'encontre de ce que je dis. Si vous voulez plus qu'on se serve du goto, alors supprimez le, et vous verrez que parfois que ça va pas être simple de coder!.

SVP, arrêtez de mettre des choses sur le forum, qui me font interagir. J'ai dit que je voulais diminuer ma présence sur le forum, alors aidez-moi, parce que moi je supporte pas les idées toutes faites.

C'est amicalement que je poste ces propos, et bienvenu CPC. (Au fait si tu n'utilise pas Panoramic, quel langage utilises-tu en dehors de Linotte?)

PS: je tiens à bien faire comprendre que malgrès tout qu'il faut éviter de mettre des goto qui montent et qui descendent pour faire un programme. Mais si vous regardez l'ensemble des programmes, les goto sont rares, donc cela n'a pas de sens.

Sans être aussi virulent (!), je suis un peu d'accord avec toi cosmos, un petit goto au milieu d'un traitement pour sauter quelques lignes en avant ou en arrière simplifie bien la programmation.
Evidemment il n'est pas question de sortir d'un sous-programme ou de se brancher dans un sous-programme avec un goto, il faut l'utiliser intelligemment en respectant la logique du programme.
Mais l'interdire, non.

Oups désolé d’avoir été si extrême avec le GOTO !

En effet, il ne faut pas l’interdire et je pense même qu’il ne faut pas mettre de règle pour le limité dans PANORAMIC comme le souhaitait Jack.

Je l’ai utilisé pendant pas mal d’années aussi… sur mon CPC 6128 !!!

De plus, Cosmos70, recommander d’utilisation le GOSUB est plus de mon expérience personnel que de la lecture de documents ou recommandation. Dans 90% des cas, tu peux arriver à réduire la taille de ton programme et le rendre plus lisible si tu passes par des GOSUB et lieu de GOTO.
Ça peut être un bon exercice de prendre un des programmes et de faire en sorte que tu supprimes tous les GOTO.

Bonne programmation

je vais me permettre une petite intervention....

je ne suis pas d'accord sur certains points

@ Jack

tes interventions sur le forum ne sont jamais de trop.
comme l'on dit, il vaut mieux un qui sait que dix qui cherchent, et qui en dehors du concepteur sait le mieux ce qu'il est possible de faire.
En plus, il est toujours agréable de voir que le concepteur suit nos évolutions personnelles et s'intéresse au sujet que l'on post même si c'est un petiit message cours pour la todo list du style "Sujet lu par Jack".
que l'on est pas comme sur certain forum l'impression de poster dans le vide.
Et c'est aussi ces interventions qui font que je me suis interessé à Panoramic plutôt qu'un autre.


@ tous

on a avec Panoramic un langage de programmation qui évolue grace à Jack
quasiment en fonction de nos besoins.
(essayer de demander cà à d'autres, une fonction de plus tous les deux jours)
de temps en temps il faut aussi admettre qu'une évolution implique quelques désagréments.

Pour la compatibilité , Perso j'ai stocké les évolutions depuis la 0.9.17
si il y a un souci je compilerai avec et repartirai sur de nouveau prog

mon avis sur les labels : je suis partagé comme beaucoup j'ai envi d'avoir fini avant d'avoir commencé et donc réticent aux complications mais celles ci en ce cas peuvent aussi éclaircir les programmes (une fonction ,un effet)

Donc je ne pense pas que ce soit à abandonner, mais je ne suis venu à la prog qu'il y a quelques semaines. .

Il est certain que le dernier programme que j'ai fait peut largement être repris. J'ai fait des essais au mois de décembre pour afficher une page entière de données en couleurs sur des fonds colorés, le programme mettait presque 30 secondes pour afficher la page entière. Je me suis aperçu alors (mais j'étais en essais, puisqu'à l'époque je crois j'étais le 1er a avoir réussi à afficher un texte coloré sur un fond coloré autre que celui de la forme) alors que mon programme faisait une quantité de boucles et je savais que tout était à revoir.

Mais mon prog. à cellules (si c'est celui-là que tu penses), ça été une découverte parce que je ne pensais pas pouvoir suivre de cellule dans le temps d'une fraction de seconde avec tous les testes qui sont avec. Donc c'était des essais, et d'approche en approche, ce programme c'est fait.

Régulièrement lorsque je programme, il n'y a pas de cahier des charges pour dire que je vais faire comme ceci ou comme cela, ce sont les découvertes qui influent sur le programme. Lorsque celui a avancé, j'évite de trop le bouleverser. Il est évident que si je pars avec une idée précise et que je sais qu'il y aura pas de problème quant au résultat, je m'arrange pour que le programme soit structuré, mais comme beaucoup ici, on est à la découverte de Panoramic qui évolu sans cesse, et on tape sur son clavier au petit bonheur la chance.

Je sais qu'un goto allant directement sur un autre sous programme qui sortira par le return de celui-ci ne pose aucun problème à Panoramic, et lorsqu'on avait pas prévu de se resservir d'un code, comme ça été le cas pour ce programme, un goto me faisait plaisir à utiliser parce dans le cas précis, plus simple pour reprendre le programme.

Moi je pense que bien souvent un programme devrait être fait 2 fois. Une première ébauche suivi du "débogage", et une réécriture de celui-ci après toute les modifications apportées pour le finaliser (et le rendre plus simple). Encore faut-il le temps pour cela.

@+
Je rajoute ceci: Si Jack pour le codage du basic et pour les nouvelles instructions, cela pose un problème, il faut le faire savoir, et nous dire les règles à respecter pour que tu n'ais pas de problème.

Je suis de retour et je viens de relire tout ce sujet.

Ma première réponse, n'impliquait pas que j'étais ravi de voir la création de 3 types de Labels, mais une approbation sur le fait de pemettre les 2 façons de programmer. Un peu comme JJN4, je me résignait.
L'intervention de Cosmos remet les pendules à l'heure et mets en évidence les inconvénients (qui en l'occurence seraient plus importants que les avantages). Cela va déclencher TRACE_ON et TRACE_OFF et c'est une bonne chose.
Je ne pense pas que Jack intervient trop sur le forum, la preuve cette discussion lui a fait changer d'avis. S'il n'avait pas diffuser ses intentions, il n'y aurait pas eu l'intervention de Cosmos....
De toute façon ce qui importe c'est que l'on avance...

Attendons pour voir,

A+

PS: Bonjour à CPC. (c'est grace au 6128 que j'ai découvert la programmation).