Instruction INCLUDE

Bonsoir,

Je propose l'ajout d'une instruction de type

include [path\]filename.bas


Elle ferait ce que son nom indique: inclure un source .bas dans le programme à l'endroit précis où l'instruction se trouve. Ce source ne serait pas affiché dans l'éditeur, mais pris en compte dans la compilation, l'exécution et la création d'un .exe, et ceci de façon transparente pour l'utilisateur.

Ou pourrait ainsi mettre plusieurs "include" dans un programme pour ajouter par exemple des définitions d'objets, des sous-programmes etc. Ceci permettrait de constituer une bibliothèque de sources avec une maintenance plus aisée des programmes. Il suffirait en effet de modifier ou corriger un fichier "include" puis recompiler tous les programmes concernés, sans avoir à apporter la même modif partout... Et l'écriture des programmes deviendrait plus modulaire, plus rapide et plus facile à maintenir. Il n'est bien sûr pas question de résolution de liens ou autres problèmes; une erreur de déclaration ou de référence ne sera détectée qu'à l'exécution ou à la compilation, pas avant (comme c'est le cas maintenant, d'ailleurs).

Qu'est-ce que vous en pensez ?

Cordialement Klaus

Salut Klaus
voici la liste que Jack a publié le 30novembre
https://panoramic.1fr1.net/ce-qui-est-en-cours-f4/liste-des-projets-au-30-novembre-2009-t436.htm
Ceci est prévu, mais il faudra de la patience. Moi en attendant j'aurai aimer avoir un éditeur à onglet comme j'en ai parlé.
https://panoramic.1fr1.net/presentation-et-bavardage-f5/editeur-a-2-onglets-t516.htm
En attendant un include avec les variables locales, ce serait un premier confort. Qu'en penses-tu.
Bonne nuit.

Ok, je vois que Jack a du pain sur la planche... souhaitons-lui d'avoir des journées de plus de 24 heures, car les projets sont multiples etintéressants. Je vois que le INCLUDE arrive relativement "loin" dans la liste ce qui me déçoit un peu, mais ce n'est évidemment pas moi qui fixe les priorités !

J'ai bien vu tes suggestions pour l'éditeur à onglets.Cela porrait évidemment apporter une grande amélioration dans la pratique, car défiler l'ensemble du source dans une seule fenêtre, chaque fois qu'il faut vérifier ou modifier une déclaration, par exemple, est quand-même fastidieux.

Ceci dit, il faut tout de même charger le fichier correspondant dans chaque volet, avec une commande "création de volet" puis "ouverture de fichier", ou déplacer certaines parties de code de l'onglet principal vers d'autres. La finalité n'est pas la même - tu proposes une plus grande facilité de gérer un large module de source alors que mon objectif est d'arriver à une plus grande modularité des sources pour pouvoir réutiliser facilement des morceaux de codes (comme une bibliothèque de sous-programmes de service par exemple) et pour améliorer les conditions de maintenance des grands programmes.

Alors, attendons que Jack ait un peu de temps disponible (ce que le lui souhaite) !

Salut, non j'envisageait de mettre une simple commande dans le programme.
Si elle n'existe pas, tout va dans le premier volet, l'ouverture.
Mais si lors de la lecture il rencontre un mot qui soit transparent dans le programme, une sorte de rem de commande, il rencontre ce mot, il va dans le bon volet. Au bout d'un certain temps, on peut dire à une partie du programme qu'ici on veut plus te voir, hors de ma vue, va ailleurs. Ce truc n'est pas très compliqué, il faut avoir en tête que de gauche à droite, le programme est la suite.
A plus

Bon, j'ai relu attentivement ta suggestion au sujet de l'éditeur à deux onglets, et tous les posts qui s'y rattachent.

Nos deux propositions sont très similaires, en ce qui concerne les problèmes techniques d'implémentation, pour autant que je peux le voir. Leur finalité et leur usage par contre cible des objectifs différents.

Il est en effet très intéressant d'avoir sous les yeux, quasiment simultanément, des parties de code qui ne sont pas consécutifs dans le programme, et d'avoir une fenêtre principale d'édition qui soit "allégée" des parties pas directement concernées avec ce que l'on souhaite faire à un moment donné. Ma proposition (INCLUDE) ne permet pas d'avoir le code en parallèle, mais permet également de réduire le programme à l'essentiel en déplaçant des parties répététives ou déclaratives.

Contrairement à ce que j'ai lu dans une des remarques concernant un possible INCLUDE, on n'a pas besoin d'avoir une possibilité de variables locales ou publiques. C'est un vaste sujet, la visibilité des variables, labels et procédures, et c'est lié au possibilités de passer des paramètres à un sous-programme ou une fonction, par exemple du type:

subroutine test(par1,par2)

end_sub

appelé par call test("Maison",17)

ou

function surface_rectangle(long,larg)
surface_rectangle = long * larg
end_function

appele par plan_travail = surface_rectangle(200,65)

On entre alors dans un niveau de langage différent, avec la possibilité d'avoir des modules "complilés" externes et les liens qui se font (ou pas en cas d'erreur), mais pour moi, je n'ai pas perçu l'objectif de PANORAMIC de cette façon. Par contre, ajouter une souplesse de rpogrammation et des moyens de faciliter la maintenance peuvent être parfaitement compatibles avec la logique actuelle, sans metttre en cause les fondamentaux de PANORAMIC. Et ceci est vrai de la même manière pour l'éditeur à deux (voir plus...) d'onglets tout comme pour l'instruction INCLUSE, car, dans les deux cas, cela se réduit à dévier le "fil de lecture" d'un programme au moment de l'exécution ou de la compilation, d'une part vers un autre onglet jusqau'à ce fin pour revenir à la suite dans l'onglet principal, ouà dévier le "fil de lecture" vers un autre fichier jusqu'à la fin du fichier. Techniquement, c'est rigoureusement identique pour PANORAMIC; ce qui change, c'est la présentation visuelle (des onglets ou pas) et l'usage que l'on veut en faire.

Cela me fait penser que si l'éditeur à onglet est réalisé, l'instruction INCLUDE l'est à fortiori ! Donc, tout ce qui va dansce sens, me semble très prometteur.

Je suis pas très sûr que tu ais complètement raison. J'ai auparavant utilisé include dans un autre basic, pour le Palm. Il n'y avait je crois de variable locales, mais à ceci près, il n'y avait pas de déclaration de cette-ci.
J'ai fais cette proposition, parce que à part l'éditeur, et je ne crois pas que cela soit si compliqué, (il faudrait peut-être en plus un bouton qui déplace ou remet le programme sur un ou plusieurs onglet (ce truc je le fais en basic en sachant que c'est plus difficile dans un autre langage (je sais pas si c'est du Pascal / du C truc muche ou autre). Un include demande un traitement à part, il lui faut des variables, et pour le développeur dont tu en ais un, ils vont être déclarés où?. J'ai regardé un peu Delphi, puisque je voulais apprendre à programmer avec, ainsi que TCL, mais le temps manquant, et passant beaucoup de temps sur Panoramic, je ne fais que tout repousser. Il y a les déclarations aussi de global ou local, mais ici? .Ce n'est pas encore fait, et je crois que ça chamboule tout, il y a à mon avis encore beaucoup de choses à transformer à ce basic pour "inclure" un "include". Ce basic va finir par ressembler à du Python. Mais moi, je ne connais rien avec mon CAP de couvreur, je suis un peu dépassé. Aussi, dans un premier temps un éditeur à onglet pour le même programme, serait un bon intermédiaire. D'autant que notre Jack non content de faire ce langage, se lance dans des projets fous, et avec le travail qu'il a déjà, notre part va en diminuant. Mais là il n'y a aucun reproche. On fait tellement mieux les choses, lorsqu'on a des idées, et qu'on les appliquent. çà donne des ailes.
A+

Klaus, toi qui veux développer des trucs. Pourquoi ferais-tu pas l'éditeur en question. C'est dans tes compétences, je le ferais bien, mais j'ai trop de chose et j'en es pour un bout de temps. J'ai un programme "multipage" qui ressemble un peu à ça, mais quand même bien différent (JL35 j'ai retenu la leçon). Oui mais il n'y aura pas de coloration. Il faudrait pour cela que ce soit fait sur un picture, et comme les scroll n'existe pas.!!! Misère.
A+
Au fait, c'est quoi les langages que tu connais. Si il y a des experts sur ce forum, pourquoi laisser ce travail à Jack. Celui qui fait du c# ou du Java peu très bien le faire, il inclut un fichier, où on rajoute les nouvelles commandes pour la coloration. Avec un bouton de copie, on le reprends avec Panoramic (je parle du programme généré avec cet éditeur spécial). J'ai pas l'impression que Jack va se lancer dans ce projet, il a trop de chose à faire.

Pour des INCLUDE, il faut des variables locales si on l'entend dans le sens que tu mentionnes. Ce n'est pas tout à fait ce que je propose. D'ailleurs, on pourrait aussi bien appeler une telle instruction external ou autre.

Le but est simplement de dévier momentanément la poursuite linéaire du source vers un fichier .bas externe, puis continuer à la ligne suivante du module d'origine. Il suffirait d'un seul niveau (pas d'autre INCLUDE dans un fichier à inclure). On ne contrôle rien, on reste dans la logique de PANORAMIC avec toutes les variables visibles partout.

Si un module à inclure a besoin de variables internes, il suffirait d'une convention de codage (personnelle à chaque personne, bien sûr), du type de préfixer chaque variable définie dans le module inclus par le nom du module, tel que je l'ai fait dans mon programme de formattage de nombres (voir dans cette rubrique). Exemple: dim format_I%, format_out$ dans on module qui s'appellerait format.bas.

Tu vois, pas de changement dans la philosophie de PANORAMIC, pas de complexification de l'usage du langage - tout reste identique. Cela agit uniquement au niveau de l'ordre dans lequel les lignes sont prises en compte, au niveau de l'exécution immédiate et au niveau de la fabrication d'un .exe. Toute erreur ou incohérence ne sera détectée qu'à ce moment, comme c'est d'ailleurs le cas actuellement dans PANORAMIC.

Et concernant l'éditeur a deux ou plusieurs onglets, la logique de définition des variables et d'exécution est exactement la même !

Pour ce qui est de l'écrire moi-même, je n'ai pas cette prétention. Je voulais juste donner une idée qui pourrait peut-être germer. A supposer que j'aie les compétences pour faire ce travail (ce qui est loin d'être sûr), je ne pense pas qu'un tel développement puisse être mené à bien par des personnes qui ne sont pas intégrées dans une structure commune assurant la cohérence des travaux... Je ne souhaite aucunement faire concurrence à Jack qui fait un superbe travail.

#INCLUDE "PROGRAMME.BAS" a été réalisé et testé, et fera partie de la prochaine version "instantanée" prévue pour mi-février lors de mon retour en France (je suis actuellement en déplacement professionnel en Arabie Saoudite).

Il n'y a pas de limites au nombre de #INCLUDE dans un source et le fichier à inclure peut lui-même contenir des #INCLUDE

Attention, cette instruction #INCLUDE est une directive. C'est à dire qu'au moment où elle est exécutée, il n'y a pas d'évaluation possible sur le nom de fichier qui doit donc être écrit littéralement.

Je m'explique par un exemple:
#INCLUDE "PG.BAS" fonctionnera, et c'est la syntaxe normale: le nom du fichier à inclure est écrit en toutes lettres,
mais les 2 lignes suivantes NE FONCTIONNENT PAS:
#INCLUDE "PG"+"."BAS"
A$="PG.BAS":#INCLUDE A$

D'autre part, attention aux #INCLUDE croisés!
Si dans PG1.BAS on trouve #INCLUDE "PG2.BAS", il ne faut pas que PG2.BAS contienne la ligne #INCLUDE "PG1.BAS"

Actuellement PANORAMIC avance plus lentement que je le voudrais, mais vers mi-février, le développement devrait reprendre son rythme habituel.

On a entendu ces jours ci de super Mami, nous on a SUPER JACK. Le monde entier va vouloir nous le voler. Faites très attention qu'il ne soit pas bloqué à la frontière au retour.
Salutation

Il y a longtemps que je rêve de l'INCLUDE, enfin c'est en vue.
On va pouvoir se constituer des bibliothèques de sous-programmes, petits ou grands, et se les partager, pourquoi pas ?
Reste une zone d'ombre, pour moi: est-ce que les déclarations de variables seront propres au programme inclus (ce que je souhaite, mais qui paraît difficile à réaliser pour le compilateur), ou communes avec le programme contenant ?
l'Arabie, c'est où, dites ?

Pour Jack:

Pour les infos sur #INCLUDE en devenir: c'est SUPER ! C'est exactement ce que je souhaitais ! Je n'en reviens pas ! Barvo, continue comme ça !

Pour JL35:

Regarde mon poste un peu plus haut, concernant les normes de programmation (personnelles bien sûr). Pour des modules INCLUDE qui ont besoin de variables "internes", une solution consisterait à donner des noms qui commencent par le nom du fichier INCLUDE (sans l'extension bien sûr), suivi d'un "_" puis du véritable nom. J'en conviens, il faut taper un peu plus de caractères, mais comme ça, il n'y a pas de conflit de variables, et de toutes les manières, il serait de bonne pratique de donner des noms de variables longs qui servent à eux seuls de documentation: le programme deviendra beaucoup plus lisible pour un tiers et plus facile à maintenir si tu reviens dessus 3 ans après...

bonjours

jai été le premier a demandé des include sa fait plusieurs mois de sa

javais arrêté de programmé avec panoramic mais la avec la bonne nouvelle on va avoir des include je vais pouvoir allé plus loin

merci panoramic aussi merci klaus je pensai que jétai le seul a vouloir des #include Lol a+

@Klaus, oui je sais, c'est une solution, mais que je trouve un peu contraignante et en recul par rapport au Basic classique avec les SUB et FUNCTION et leurs variables internes indépendantes (ou communes avec SHARE). Enfin, j'ai été habitué comme ça il y a bien des lunes.
En Basic je m'étais fait une grosse bibliothèque de SUBs que je pouvais insérer à la demande dans n'importe quel nouveau programme, sans souci des noms de variables (sauf les paramètres d'appel).

C'est vrai que de vrais modules indépendants comme dans d'autres implémentations de Basic seraient intéressants.

Mais alors là, on va jouer dans une autre catégorie, celle des programmes compilés avec résolution de liens dans une phase d'éditions de liens (link), pour pouvoir lier le programme de base aux modules externes, tant par leur nom ou référence que par leurs paramètres. Cela impose la création d'une table de symboles vectorisée dans chaque module compilé, et on résoud les liens par rapport à cela.

C'est bien sûr puissant, mais on perd l'ouverture et la facilité de PANORAMIC. Cela rend aussi beaucoup plus difficile de "debug", soit l'exécution immédiate dans l'éditeur, sans passer par la construction d'un exe, car on a alors aucun moyen de connaître les liens vers les autres modules. Même si l'on imagine passer par une déclaration des routines appelées dans le module appelant, un peu comme l'instruction "label", en précisant exactement le chemin vers le module (comme dans #INCLUDE), on ne pourrait pas établir le lien avec la routine appelée dans le module source ciblé car lui-même n'est pas compilé et n'a donc pas de table de symboles. Une usine à gaz...

Bien sûr, PANORAMIC, tel qu'il est, n'est pas encore mûr pour servir d'outil de création d'une lourde application de gestion, un peu à cause de ce problème de modularité, mais beaucoup plus par le manque d'accès à une gestion souple de fichiers indexés ou de bases de données comme ACCESS, DBASE etc. Donc, c'est un outil parfait pour réaliser des jeux, des logiciels persos orientés gestion, etc. Si je veux un outil gratuit avec la modularité complète, j'utilise Visual Basic V4 (qui est maintenant un VetusWare donc officiellement gratuit), mais c'est un porte-avion par rapport à la vedette PANORAMIC.

Je n'ai accès à internet que 10mn/jour.
Je répond juste à JL35:

Citation :

Reste une zone d'ombre, pour moi: est-ce que les déclarations de variables seront propres au programme inclus

Non parce que #INCLUDE "PG.BAS" ne fait que remplacer la ligne #INCLUDE par le texte de PG.BAS.

C'est comme dans un traitement de texte lorsqu'on inclut un autre document.

Ok.donc si je comprends bien, include ne fait qu'un copie/coller d'un programme qui serait sur un autre éditeur. Je vais en tenir compte dans ce que je me prépare. En réalité c'est la même chose que mon idée d'un éditeur à x onglet, ou que le repliement d'une procédure, on voit le mot include au lieu du sous programme.

Citation :

Si je veux un outil gratuit avec la modularité complète, j'utilise Visual Basic V4 (qui est maintenant un VetusWare donc officiellement gratuit), mais c'est un porte-avion par rapport à la vedette PANORAMIC.

C'est justement une des raisons pour laquelle je préfère PANORAMIC. Je n'aime pas les portes-avions, çà sous entends un manque d'indépendance et surtout une complexité que je ne souhaite pas.
Serte, aujourd'hui, PANORAMIC est limité, mais on pourrait en reparler dans plusieurs années.
Ma crainte principale c'est que PANORAMIC perde son âme. Des gens comme moi (et je pense que l'on est nombreux), ont besoin d'un d'un logiciel de programmation accessible à tous, parce que nos connaissances en programmation sont limitées.
Bien sur, il ne faut pas que PANORAMIC arrête d'évoluer, c'est pourquoi je pense qu'a un moment il y aura le PANORAMIC que nous connaissont (avec ses améliorations continues) et, sans vouloir me substituer à Jack, un logiciel un peut plus coté porte-avion, qui à mon avis est la finalité. Et comment en vouloir à son créateur ( c'est une suite normale des choses).

Ces propos n'engage que moi, simplement çà me parait envisageable. Mon seul espoir est que les novices de la programmation, conservent PANORAMIC avec sa simplicité, sa gratuité et en même temps sa performance.
Mais là, je pense que ce n'est pas pour demain matin.

A+

@Jack, oui, c'est bien ce que je supposais, donc il faudra bien appliquer la méthode de Klaus, c'est à dire mettre dans les morceaux de code à inclure des noms de variables bien particuliers qui leur seront propres.
A priori on peut mettre les déclarations un peu n'importe où (avant utilisation quand même), donc en tête des morceaux inclus.
Et il paraît logique de mettre ces include au début du programme principal.

@Jean-Claude je ne pense pas que tu aies de crainte à avoir concernant l'évolution de Panoramic, ceux qui ne voudront pas trop se casser la tête ni utiliser des fonctions sophistiquées dont ils n'auront pas besoin pourront toujours se contenter des fonctions existantes, parce que j'ai cru comprendre que Jack a à coeur de conserver la compatibilité avec l'existant.
Qui peut le plus peut le moins, ça ouvrira des horizons à certains, mais d'autres (dont moi sans doute, sauf exceptions) se contenteront des fonctions de base qui sont déjà assez puissantes, avec quelques améliorations.

Jl35, ce n'est pas une crainte, juste une réaction aux propos de Klauss qui (il le dit) nous ferait jouer dans la coure des grands. Mais effectivement, comme tu le souligne, nous ne seront pas obligés d'utiliser la puissance d'un porte-avion. En résumé, un porte-avion Oui, mais avec la vedette embarquée.


Il faut tout de même que je donne mon avis (en forme de question à tous) sur le sujet de ce poste:

Si j'ai bien compris, INCLUDE permettrait de faire appel à des routines et les intègrerait dans le programme exe pour exécution, sans qu'elles soient intégrées au code source. Ou serait-ce différent ?

A+

Je ne pense pas qu'il y ait des craintes à avoir pour l'avenir de Panoramic.
C'est simple parce que son constructeur veut que ce soit simple,
et non parce qu'il n'y a pas toutes les fonctions des programmes plus anciens.
Cela peut être plus complet tout en restant simple, si on le veut.
Je connais aussi un peu Visual Basic 2008 Express,
et j'ai très bien compris qu'il est compliqué, non pas parce qu'il y a beaucoup de choses dedans,
mais dans le but non avoué de le réserver seulement aux initiés...
(et parce que pour obtenir des cours, il faut payer dans la plupart des cas)
Il y a dedans des tas de choses qui sont inutilement compliquées.

Je le répète, je n'ai pas de craintes. Juste une réflexion. Ton opinion, JJN4, sur visual basic, je la partage.
A+

J'ai également été tenté par des langages plus élaborés (dont Visual Basic), mais j'ai vite abandonné, trop compliqué pour mes besoins.

Jean-Claude, pour le INCLUDE je crois que tu as bien compris, ça représente simplement un morceau de code qui ne sera pas visible dans l'éditeur, mais qui sera bien interprété au moment de l'exécution (et de la compilation) comme s'il faisait partie du source.
Si ton programme principal s'appelle MonProg.bas et que tu y mets #INCLUDE MesSubs.bas, ce sera exactement comme si tu faisais un copier/coller du contenu de MesSubs.bas à l'emplacement du Include.
Seul avantage: ne pas surcharger l'affichage du source dans l'éditeur, c'est simplement comme si on cachait un morceau du source à l'affichage, mais pour le reste ça ne change rien.
Pour moi je vois ça comme une partie de source réutilisable telle quelle dans d'autres programmes sans avoir à la réécrire.

Il faudra simplement faire attention aux noms de variables DIM et LABELs déclarés dans le module inclus pour qu'il n'y ait pas conflit avec des variables déjà déclarées dans le programme principal. Et idem pour les numéros d'objets système.
Et problème pour les variables communes (il y en aura forcément, puisqu'il y aura échange de données entre les deux zones), où les déclarer ? probablement dans le module principal, mais alors le module inclus sera moins universel puisqu'il faudra penser à déclarer certaines variables, pas toutes, chaque fois qu'on le réutilisera ailleurs.

Bonsoir, JL35,

Pour l'indépendance des variables et labels, bien sûr, il faut faire attention. Regarde mon post un peu plus haut, où j'ai suggéré une technique possible pour résoudre cela. Il y en a d'autres. Le tout, c'est de garder effectivement à l'esprit que si l'on veut faire une "collection" de modules ou sous-programmes indépendents (et c'est cette utilisation de INCLUDE qui m'intéresse), il faut choisir une technique d'assigner des noms réservés à chaque module de façon univoque, et on peut ainsi recombiner ces modules à volonté. C'est une question de discipline d'écriture, et la lisibilité et la maintenabilité y gagneront.

Citation :

C'est simple parce que son constructeur veut que ce soit simple

@ jjn4:
Voila, tu as tout dit.
PANORAMIC ne dérivera pas vers la complexité, mais restera un logiciel fait pour les humains.

Citation :

pour le INCLUDE je crois que tu as bien compris, ça représente simplement un morceau de code qui ne sera pas visible dans l'éditeur, mais qui sera bien interprété au moment de l'exécution (et de la compilation) comme s'il faisait partie du source.
Si ton programme principal s'appelle MonProg.bas et que tu y mets #INCLUDE MesSubs.bas, ce sera exactement comme si tu faisais un copier/coller du contenu de MesSubs.bas à l'emplacement du Include.
Seul avantage: ne pas surcharger l'affichage du source dans l'éditeur, c'est simplement comme si on cachait un morceau du source à l'affichage, mais pour le reste ça ne change rien.
Pour moi je vois ça comme une partie de source réutilisable telle quelle dans d'autres programmes sans avoir à la réécrire.

Il faudra simplement faire attention aux noms de variables DIM et LABELs déclarés dans le module inclus pour qu'il n'y ait pas conflit avec des variables déjà déclarées dans le programme principal. Et idem pour les numéros d'objets système.

@JL35:
Je n'ai rien à ajouter, c'est exactement ça.
C'est un premier pas vers la création de bibliothèques de fonctions: on n'a plus à les retaper.
Le pas suivant sera des variables locales et du passage de paramètres. On n'aura plus à se soucier de regarder si on n'interfère pas avec une variable portant le même nom dans le fichier à inclure.
Pour le moment, cela se voit toute de suite: lors du deuxième DIM, il y a erreur, de même que pour la deuxième création d'un objet portant le même numéro.
si je fais:
dim a
#include "pg.bas"

et que dans pg.bas, il y a aussi dim a, une erreur sera signalée, et il faudra corriger pour que ça fonctionne. L'utilisateur est averti.

c'est exactement pareil pour les objets:
si je fais:
button 1
#include "pg.bas"

et que dans pg.bas, il y a aussi button 1, une erreur sera signalée, et il faudra corriger pour que ça fonctionne.