Instruction INCLUDE

Tout est bien clair concernant le #INCLUDE, et en attendant les variables locales (ce qui sera sans doute beaucoup plus tard, mais sera selon moi un gros progrès), je suis d'accord avec la méthode Klaus, il faudra adopter une discipline pour le nommage des variables incluses pour éviter les doublons, puisque comme lui je pense surtout à des collections de routines réutilisables dans d'autres programmes.

avoir ses routines et les intégrer dans le programme, çà va être super, et terminé les copier/coller qui prennent de la place dans le code principale ! Encore une évolution importante. Finalement le porte-avion se dessine.

Merci à Jack de nous rassurer sur la complexité de PANORAMIC, et en relisant ce que j'ai écris, je m'aperçoit que j'avais utilisé le mot crainte. En fait je n'en avait pas, c'est juste que Klauss m'a fait Gamberger avec son porte-avion. Mais il n'empêche qu'au bout du compte, nous sommes tous d'accord sur ce que nous souhaitons et en plus dans la droite ligne de ce que voulait faire Jack. Si c'est pas de la démocratie, c'est surement des besoins communs ou de la télépathie. Peut-être, tout simplement, le bon sens.

Vivement la nouvelle version.

A+

Une simple réflexion!
J'ai dans mon programme des datas, et je me suis dit: si je veux que le programme ne pose pas de problèmes si il se trouve ensuite appelé par INCLUDE, je vais mettre dorénavant au départ RESTORE étiquette du programme, ainsi lorsque je lirais les datas du programme,, il saura lesquels il devra lire, puisque tout programme peut avoir ses datas. Or je me trouve avec "instruction inconnu". Et oui, pour l'instant ne fonctionne que RESTORE tout cours, sans étiquette.
Je vous laisse à vos réflexions.

Je crois bien que le RESTORE Etiquette a déjà été demandé et pris en compte par Jack.
https://panoramic.1fr1.net/vos-souhaits-d-amelioration-de-panoramic-f8/deux-petites-requetes-data-read-restore-et-2d_xx-t459.htm?highlight=restore
(la fonction 'Rechercher' a son utilité...)

ok d'accord, seulement include ne pourra vraiment être opérationnel que si RESTORE data est conçut. Sinon si plusieurs programme ont des datas à lire, il faudra revoir toute la programmation pour utiliser include. Je ne sais quel est le délai pour restore, mais je pense que les deux instructions vont de père et j'ai ouvert ce sujet pour qu'on en soit conscient. Moi même j'oublis bien des choses, même lorsque je crois avoir tout prévu.

Bonjour,

Quelques petites reflexions sur RESTORE avec INCLUDE.

On peut utiliser INCLUDE pour beaucoup d'objectifs très différents:

Cas 1: on veut découper un grand programme unique en modules plus maniables, afin de les manipuler plus facilement dans l'éditeur.
==> on garde les mêmes contraintes par rapport à RESTORE qu'avec un programme en un seul morceau (car pour le compilateur, C'EST un seul morceau), et donc un RESTAURE dans un INCLUDE affecte globalement la position de lecture dans les DATA partout dans le programme. On garde donc le même logique qu'actuellement.

Cas 2: on veut pouvoir créer une "collection" de sous-programmes ou modules fonctionnels.
==> Dans ce cas, RESTORE est à proscrire dans un module INCLUDE ainsi que l'utilisation des données en DATA, pour les motifs décrits plus haut. Il est clair que dans un module "réutilisable", rien ne doit dépendre d'un contexte dynamique en-dehors de ce module. Mais pour cette utilisation, ce n'est pas une restriction, car l'utilisation de RESTORE n'aurait aucun sens.

Cas 3: on extrait toutes les déclarations de variables dans un module, toutes des créations d'objets pour une form dans un autre, etc.
==> On obtient alors un programme contenant les procédures évènements et la procédure principale; les RESTORE sont possibles sans problème comme pour un programme en un seul morceau (à supposer que la création des objets n'utilise pas de données en DATA, sinon, voir plus haut !). On peut même pousser la logique plus loin en délogeant les routines évènements pour les boutons dans un module à part, pour d'autres objets dans un autre module et ainsi de suite. Les possibilités sont infinies et dépendent en fait de l'objectif que l'on se fixe pour gérer son code.

Dans mon cas personnel, je cherche à rationnaliser la maintenance du code existant et à modulariser l'écriture de nouveaux programmes en utilisant justement une collection de modules indépendants. Dans cette optique, l'utilisation de RESTORE est bien sûr réservé au module de premier niveau (celui qui contient les INCLUDE), et cela ne pose pas de problème.

La directive INCLUDE est tellement polyvalente que de vouloir la conditionner par l'adaptation de RESTORE me semble un peu dur pour ceux qui souhaitent en faire un autre usage...

Cordialement Klaus

bonjour,
Pour ma part depuis que j'ai posé le problème, j'ai décidé d'enregistrer les datas dans un fichier, puis de modiifer le programme pour les récupérer dans DLIST pour cette occasion, ainsi maintenant au démarrage, je charge la liste et je travaille carrément avec celle-ci, et j'oublis les datas, et tout se résolu.

C'est évidemment une excellente solution au problème des DATA. Pour ma part, j'ai toujours considéré que DATA, RESTORE et compagnie étaient des archaismes datant de l'époque où l'on traitait des données par lot, sur cartes perforées par exemple. Je ne les utilise pas; j'utilise des fichiers de type .INI, mais chacun peut avoir uune préférence pour une méthode ou une autre. Mais ton post illustre bien qu'en réalité, la problématique DATA/RESTORE peut être considéré de façon totalement indépendante des INCLUDE, ce qui était mon sentiment.

Alors, imaginons des solutions pour que les outils disponibles puissent donner accès aux méthodes modernes et je suis sûr que PANORAMIC continuera à évoluer dans le sens de la modernité sans tomber dans la lourdeur. En relisant tout le forum, je pense que c'est bien là qu'est la préoccupation de Jack, et c'est tant mieux.

J'ai pensé à cette solution depuis que j'ai posé le problème. Mais je ne rejoins pas ton idée de dire que ces instructions sont archaïques. Le basic est un langage de programmation simple, et autant que faire, doit le rester. Les professionnels ont d'autre langage à leur disposition, et on fait les études et passé le temps nécessaire pour les utiliser. A moins que ceci veulent avoir la maitrise de la programmation et font le nécessaire pour avoir chasse gardée, on se doit de défendre nos points de vue et d'avoir un langage simple. Certes on peut contourner les datas, mais lorsqu'on a des petits programme à faire, se servir des datas pour résoudre un problème est quand même plus simple, surtout pour poster un programme sur un forum, qui n'oblige pas de poster un fichier secondaire avec le programme. De plus pour de petites quantité de donnés, il est plus simple d'écrire une ligne de data que de dire par exemple:
nom_objet$(1)="machin":nom_objet$(2)="truc":nom_objet$(3)="bordel" etc
ou bien item_add 1,"machin":item_add 1,"truc":item_add 1,"bordel"
Si il y en a 3, ça va, mais 10 c'est déjà plus "chiant", et moins beau à lire.
Il y a les fichiers pour gros volumes. Les datas c'est pour les petites listes et c'est l'idéal pour un programme qu'on met sur le forum.
Si on part sur le principe que data est archaïque, à ce moment là, il y en plein dans le basic, et avec cette idée ont ne programme plus. Pourquoi faire simple lorsqu'on peut faire compliquer? Si une chose peut se faire simplement, cela me parait idiot de chercher à faire la même chose en compliquant tout.
En disant cela, jjn4 va penser que je ne suit pas cet exemple en montrant une possibilité de faire un memo enrichi et se disant que de toute façon Jack va sortir un mémo riche. Moi j'ai toujours programmé avec les outils que j'avais en main, quant à l'avenir je ne le connait pas, et je ne sais pas comment fonctionne un mémo enrichi.
Je pense que pour ma part le problème d'INCLUDE ne sera pas un obstacle pour moi, je suis en train de me faire un éditeur en Panoramic, avec des onglets, et un tas d'outils pour faciliter la programmation, avec la possibilité de modifier les variables d'autre programme, et des tas de choses qui ne sont pas de ce poste. Mais ça ne concerne que moi.
@+

Ce suis d'accord avec vous: pour de petits programmes et des programmes à publier sur le forum pour illustrer un point technique, les DATA sont une bonne solution pour éviter un fichier externe.

J'étais plutôt motivé par mon expérience avec de gros programmes en BASIC interprété d'autres programmeurs que j'au dû reprendre en maintenir, et là, j'ai souvent trouvé des pages entières de DATA avec des nombres entiers, qui servaient par exemple à générer une bitmap ou des sons, ou alors tonnes de lignes similaires représentant en réalité des fichiers de paramètres (codes postaux, listes de clients, etc). Eh oui, j'ai vu tout ça dans des DATA, et bien plus encore. Tout était bon pour éviter un fichier de données, afin de pouvoir distribuer une application en un seul fichier.

Aujourd'hui, on n'est plus soumis à de telles contraintes. Un programme généré en .EXE peut contenir des ressources intégrées, si on le souhaite, tels que des fichiers .BMP.

En fait, mon argument initial était uniquement pour dire que l'usage des DATA n'a en réalité rien à voir avec l'usage des INCLUDE, directive à laquelle je tiens beaucoup. Il est évident qu'une discipline de programmation permet aisément de gérer les conflits potentiels; il en est de même d'ailleurs pour les noms des variables et SUB's internes, avec les canaux ouverts pour des fichiers externes etc.

Je n'ai donc rien contre les DATA dans leur principe, et j'attends impatiemment les INCLUDE !

Cordialement Klaus

Bonjour
Vu comme ça , c'est bon
C'est vrai que des tonnes de data dans un programme, c'est pas très élégant, et justement mon problème est de pouvoir parcourir un programme, sans être gêné. La commande INCLUDE est faite en parti pour cela. (ça va pas te plaire, mais subitement je pense que INCLUDE pourrait être des datas). C'est pas le but.Sur Atari j'ai eu interpréteur qu était GFA Basic, et j'ai eu les 2 versions. Il n'y avait pas include, mais la 1ère version avait le même principe que Panoramic pour ainsi dire, et la 2ème version avait la particularité de pouvoir replier les procédures. C'était le jour et la nuit pour les grands programmes, on ne" voyait que la ligne des procédure qu'on ne voulait pas voir. çà aura la même apparence avec include, sauf que évidemment on ne peut les déplier, il faut rouvrir les fichiers pour les lire et les transformer.
Moi, tant que le basic reste simple, et que c'est la volonté qu'il le reste au maximum, je suis content. Si certains veulent du compliqué, les langages ne manquent pas. Déjà mes idées dépassent mes possibilités de programmer, si en plus, il faut multiplier par 2 ou 3 la conception d'un programme, j'arrête tout de suite. Il y a tant de chose à faire. Heureusement qu'on est en hiver, pendant les beaux jours, la programmation va chuter un bon coup. Alors que les choses restent simple, S.V.P. merci
Cordialement.

D'un autre côté, ce n'est pas parce qu'il y a des commandes sophistiquées qu'on est obligé de les utiliser, si on n'en a pas l'intérêt.
L'essentiel est que ça reste compatible avec l'existant, et ça c'est la volonté de Jack je crois, les nouvelles fonctions n'interfèrent pas avec ce qui existe déjà, ce n'est que du plus à utiliser ou non.

Pour les datas, c'est bien évident que c'est valable, et bien utile, pour un nombre limité de données, sinon c'est le fichier joint. Mais quand on peut éviter les fichiers annexes qui doivent toujours accompagner le programme (avec quelques risques) c'est quand même mieux, à mon avis.

Je crois qu'on se rejoins tous sur cet avis. Tout a une utilité dans le basic, même les vielles commandes. On les utilisent selon ses besoins et selon les cas particuliers. Je ne vois guère que input ici, dont je vois mal comment m'en servir, vu qu'elle n'est pas au point, mais de toute façon, on ne pourrait rien faire de propre avec.
Le plus gros soucis que j'ai avec Panoramic est de faire de la saisie clavier, et d'écrire sur un picture. Je ne touve pas de solution fiable. Je regrette l'absence d'une instruction du gente : void inp( port clavier ) qui est une attente de la pression d'une touche sur le clavier. Bouclé dans repeat:until ne me donne rien de fiable. La saisie dans un edit n'est pas mieux. Il faudrait pouvoir accepter une phrase par un <return> et naviguer avec les flèches dans le picture. Je sais le faire avec les flèches, mais avec edit, rien ne va bien. Je sais pas si quelqu'un a résolu ce problème. Si il faut mettre des boutons partout pour monter ou descendre, et éditer, vous parlez d'un confort.
C'est quand même curieux, lorsque j'ai fait les testes avec inkey$, en faisant un gosub avant le END, cela fonctionnait, et curieusement à partir du programme, le code inkey$ reste à zéro. Pour l'instant je mets mon incompétence en avant, mais je fini par penser qu'il y a un bug dans cette fonction. Je suis parti bien loin, on était dans INCLUDE, mais ça me gêne de rouvrir un nouveau sujet, surtout que je n'aurais pas la solution. Et moi poser uhn sujet dont je n'aurai pas de résultat, "ça me fou le boules".
@+

J'ai essayé aussi input$ et scancode, et il est vrai que des caractères peuvent être perdus; boucler sans temporisation sur un scancode marche bien, mais si une touche est frappée pendant le traitement et relachée avant la fin de celui-ci, elle est perdue...

Il serait sympa d'avoir une option de type SCANCODE_WAIT_ON et SCANCODE_WAIT_OFF, selon le modèle INPUT_REDO_ON etc. Si SCANCODE_WAIT_ON est actif, SCANCODE ne retournerait jamais 0, mais toujours la dernière touche frappée, avec SCANCODE_WAIT_OFF (qui serait le défaut), SCANCODE fonctionnerait comme aujourd'hui...

Voilà juste peut-être une piste pour aider dans ce contexte.

Je vais mettre dans les bug maintenant. Je suis sur que inkey$ a un bug
Merci pour ta recherche.
@+

J'ai trouvé le truc. Jusqu'à présent les essais je le faisais avec un EDIT. Seulement voilà, un edit présente un inconvénient: les flèches haut et bas, il les récupère pour en début ou fin de ligne. J'ai fais l'essai avec un mémo, dont je ne me sers que de la 1ère ligne. Le faire avec plusieurs lignes était problématique, vu qu'on ne connait pas la position du curseur, ni en colonne, ni en ligne. Et là j'ai réussi à faire ce que je voulais.

Code:

dim b$,v%,a$,a%
label clavier,bas,haut,incruste_sur_image
full_space 0
memo 1:width 1,600:height 1,35 :font_size 1,14 :color 1,180,255,156:on_change 1,clavier
memo 3:left 3,820:width 3,400:font_size 3,12 :height 3,600:color 3,240,240,200
alpha 9:top 9,65:left 9,280:caption 9,"PICTURE"
picture 10:top 10,80:height 10,500:width 10,600:font_size 10,14
v%=1
end
' ----------------------------------
clavier:
  if v%=0 then v%=1:if count(3)>0 then a$=item_read$(3,1):item_add 1,a$
  repeat
    b$=inkey$
    if (key_down_code=3 and key_down_special = 3 ) then exit_repeat
    if scancode =40 or scancode =13 then goto bas
    if scancode =38 then goto haut
  until scancode=27
  wait 100

 stop
return
            ' v% pour vertical
bas:
    repeat:until scancode=0
    a$=item_read$(1,1)        :' le mémo vert
    if count(3)<v%
      item_add 3,a$
    else
      item_delete 3,v%
      item_insert 3,v%,a$
    end_if
    ' ---
    gosub incruste_sur_image
    v%=v%+1
    2d_line 1,(v%-1)*25+1,1280,(v%-1)*25+1
    2d_line 1,(v%-1)*25+22,1280,(v%-1)*25+22
    a$=item_read$(3,v%)      :    clear 1:item_add 1,a$+chr$(0)
    return
    goto clavier

haut:
    repeat:until scancode=0
    a$=item_read$(1,1)
    item_delete 3,v%          :    item_insert 3,v%,a$
    gosub incruste_sur_image
    if v%>1
        v%=v%-1
        2d_line 1,(v%-1)*25+1,1280,(v%-1)*25+1
        2d_line 1,(v%-1)*25+22,1280,(v%-1)*25+22
        a$=item_read$(3,v%)    :    clear 1:item_add 1,a$+chr$(0)
    end_if
  goto clavier
 
incruste_sur_image:
    2d_target_is 10          :    2d_fill_color 255,255,255 :' efface la ligne avant de réécrir
    print_target_is 10        :    font_color 10,255,255,255
    print_locate 1,(v%-1)*25  :    print string$(200," ")
    font_color 10,255,0,0
    print_locate 1,(v%-1)*25  :    print a$
return

j'ai oublié: sortie par <esc>
C'est dommage qu'il ni a pas de place pour les trucs et astuces, cela aurait été sa place.
A propos pour scancode pour ce que tu dis, il fonctionne, il faut mettre un peu de ligne de codage, mais moi le problème je l'avais avec surtout inkey$, qui ne fonctionnait pas. Quant à se servir de scancode pour récupérer les touches du clavier, ça ne fonctionne qu'avec les majuscules. Pour récupérer les minuscules, ça va aussi, sauf que les caractères accentués, les signes divers n'ont pas le même code que la table ascii.

Si certains ont essayé ce programme, il ont vu que ça ne marchait pas. La copie n'a pas été faite depuis le bon éditeur Panoramic.
J'ai recopié depuis le forum ce que je viens d'envoyer, et le teste est bon.

Il y a quelque chose qui je gêne dans ce programme, et c'est d'ailleurs pour cela que je viens de poster un message concernant NUMBER_EVENTS.
L'appel des sous programmes se fait grâce à ON_CHANGE 1,clavier. Chaque fois que je rajoute une lettre ou que je modifie le texte du mémo, j'empile une adresse, et je ne vois pas, je ne comprends pas comment cette adresse se dépile. Et je crois qu'il en ait de même de on_change pour plein de chose. Est-ce que c'est logique? Ayant fait de l'assembleur sur le vieux 6502, cela me choque. Mais peut-être que c'est devenu dans l'ordre des choses aujourd'hui. Si quelqu'un a une réponse.

Le message de number_events était lu avant le STOP du programme. le résultat était de 18, j'ai pas compté mais devait correspondre aux nombre de lettres tapées au clavier.

Voila. j'ai l'habitude de programmer avec des procédures ou des sous-programmes. Le code est plus simple surtout pour la mise au point.
Un seul fichier a éditer.Aussi pour le développement a propement dit du programme principal qui est plus court et moins foulli.

Des "include" existe aussi dans d'autres programmes. Les sous-programmes
sont aussi dans l'IDE,et,cela est tres pratique pour la mise au point. Mais ceci
est ma propre façon de programmer.

C'est un peu la façon de programmer de tous ceux (la plupart) qui viennent du Basic.
Le problème ici en Panoramic ce sont les objets systèmes et les variables qui sont communs à toutes les parties du programme, et c'est bien ce qui fait toute la difficulté de développer des sous-programmes indépendants à inclure à la demande, il y a forcément des collisions.
Peut-être un jour Jack nous trouvera-t-il un moyen de rendre des routines indépendantes du reste (à part les paramètres à passer), mais personnellement je ne rêve pas trop.

A propos, bienvenue à toi dans la communauté !

Merci pour ta réponse aussi rapide. Je n'ai aucune idée de l'organisation de la programmation de Panoramic. cela est bien dommage pour l'organisation du code de nos programmes. Est-ce que cela serait plus facile si les variables dans les programmes "Include" étaient locales uniquement.

Bien sûr ce serait plus facile... pour nous ! mais pas pour le concepteur de Panoramic.
Dans l'était actuel, le #include n'est que le fait de lire un fichier texte (donc contenant un morceau de code source) et de le recopier tel quel à cet emplacement dans le source. Au moment de la compilation c'est exactement comme si on l'avait tapé ici dans le programme. C'est juste une facilité d'édition, mais ça n'intervient pas dans la compilation.
Ce qu'il faudrait peut-être, c'est qu'en plus des sous-programmes (appelés par Gosub) il y ait une notion de SUB indépendantes, avec leurs propres variables...
La question a déjà été soulevée, mais peut-être qu'on reste trop dans la logique du Basic, et ce n'est pas la philosophie de Panoramic.

La logique de Panoramic, pour faire simple, c'est de planter le décor, dessiner l'interface utilisateur avec des objets système numérotés, fenêtres, boutons, affichages, puis de se mettre en attente d'événement sur le END (clic sur un bouton, un objet quelconque). Chaque événement est traité dans une routine dédiée, puis le programme se remet en attente.

Jack a dit récemment que les sous-programmes indépendants avec passage de paramètres vont venir ! C'est prévu - parole de Jack (si le puis me permettre).

Si ça se fait, pour moi ce sera un petit pas pour Panoramic mais un grand pas pour l'humanité. Plus besoin de réinventer la poudre en réécrivant les mêmes sous-programmes à chaque fois et en tenant compte des variables déjà déclarées ailleurs dans le programme.
A nous les collections de sous-programmes universels, pourquoi pas échangeables entre membres du forum ?

Oui; j te recopie le post intégral de Jack à ce sujet:

Citation :

Sujet: RE: Petite question à Klaus
Jack

Réponses: 8
Vus: 94
Rechercher dans: Présentation et bavardage Sujet: Petite question à Klaus Ven 16 Avr 2010 - 7:54
Citation:
on pourrait alors passer des paramètres en entrée et sortie d'un sousprogramme, écrire une fonction en Panoramic pour retourner une valeur

Cela, c'est pour bientôt; et sans phase d'édition de liens.

Effectivement, je l'avais lu mais j'avais oublié... eh bien il y a de l'espoir sérieux alors, puisque c'est programmé.
Merci Klaus de m'avoir rafraîchi la mémoire.