Extension des fichiers sources de #INCLUDE

Bonsoir les Panoramiciens!
J'ai par hasard tester ce petit inutilitaire d'amateur qui n'est pas très important mais sympa dans la mesure où l'on souhaite tout simplement changer l'extension des fichiers sources pour #INCLUDE comme des sous programmes externes avec des extensions non <*.bas>. C'est pour montrer que PANORAMIC exécute le fichier source même si il n'a pas d'extension <*.bas>.

Code:

label clic
initialisation()
end

#include "sub.bot"
#include "sub.bas"
#include "sub.xxx"

clic:
  if clicked (3) = 1 then affiche()
  if clicked (4) = 1 then sss()
  if clicked (5) = 1 then Run()
  if clicked (6) = 1 then quitter()
return

SUB initialisation()
  DIM_LOCAL I%
  BUTTON 3 : TOP 3,50 : LEFT 3,10 : WIDTH 3,100 : CAPTION 3,"Sous Prog 1"
  BUTTON 4 : TOP 4,50 : LEFT 4,130 : WIDTH 4,100 : CAPTION 4,"Sous Prog 2"
  BUTTON 5 : TOP 5,50 : LEFT 5,250 : WIDTH 5,100 : CAPTION 5,"Sous Prog 3"
  button 6 : top 6, 100 : left 6,250 : caption 6,"QUITTER"
  FOR I% = 3 to 6 : ON_CLICK I%,clic : next I%
END_SUB

SUB quitter()
  terminate
END_SUB

Les sous progrmmes:
sub.bot

Code:

sub affiche()
dim_local a$
a$="Ceci est le sous programme n* 1 avec extesion <*.bot>"
message a$
end_sub

sub.bas

Code:

sub sss()
dim_local a$
a$="Ceci est le sous programme n* 2 avec extension <*.bas>"
message a$
end_sub

sub.xxx

Code:

sub Run()
dim_local a$
a$="Ceci est le sous programme n* 3 avec extension <*.xxx>"
message a$
end_sub

A+

Salut Topmozika.

En réalité la directive #include, n’exécute pas un code . Elle inclut seulement le contenu du fichier spécifié à l’endroit où se trouve la commande. Peu importe le nom et/ou l’extension donnés à ce fichier, pourvu que son contenu soit du texte !

J’espère n’avoir pas écrit une connerie!

Non, Papydall
c'est tout à fait ça...
Tu peux donner l'extension que tu veux....

Je confirme ce que dit papydall:

Citation :

En réalité la directive #include, n’exécute pas un code . Elle inclut seulement le contenu du fichier spécifié à l’endroit où se trouve la commande. Peu importe le nom et/ou l’extension donnés à ce fichier, pourvu que son contenu soit du texte !

De plus, cette opération d'inclusion de fichier dans le source est effectuée dans l'éditeur avant de passer le source complet au noyau panoramic.exe

#include est une directive de l'éditeur, qui est exécutée AVANT toute exécution du source par panoramic. Ce n'est pas une instruction.

J'avais aussi codé la directive #const de l'éditeur qui permettait d'utiliser des constantes dans le source, mais je l'ai dèsactivée à l'époque, à cause de l'incompréhension des directives et du nombre élevé de questions récurrentes sur le forum.
Aujourd'hui, je pense que le "public" est prêt à utiliser les directives.

@ Papydall, Nardo26, Jack
MERCI A VOUS DE CES RÉACTIONS. Franchement je ne savais pas trop comment auparavant exploiter cette commande #INCLUDE que j'imagine être utile pour des codes trop long pour pouvoir les séparer en 2 ou 3 fichiers sous-programmes. Alors j'ai testé pour obtenir ce que je désire. Et c'est pour dire aussi comment ce forum est très utile et instructif à ce point.
MERCI ENCORE.
A+

La directive #INCLUDE fonctionne comme le préprocesseur du langage C. C'est une sorte de traitement de texte qui effectue des remplacements. On transforme ainsi le fichier source d'origine en un autre fichier source. C'est ce dernier qui est compilé, mais l'utilisateur ne voit que le fichier d'origine, d'où le risque de bugs ...

En ce qui concerne CONST, il y a deux façons de l'implémenter :

* soit sous la forme utilisée par QuickBasic, FreeBasic ou Delphi :

Code:

const Pi = 3.14159

On utilise alors Pi comme une variable, dont la valeur ne peut toutefois pas être modifiée.

* soit comme une directive (analogue à #DEFINE du C) :

Code:

#const Pi 3.14159

Le préprocesseur va alors scanner tout le source et remplacer systématiquement toute occurrence de la chaîne "Pi" par la chaîne "3.14159", exactement comme on le ferait avec un traitement de texte. C'est le résultat de tous ces remplacements qui sera compilé.

La première solution est plus simple, mais c'est à Jack de choisir.

à Jack

Citation :

J'avais aussi codé la directive #const de l'éditeur qui permettait d'utiliser des constantes dans le source, mais je l'ai dèsactivée à l'époque, à cause de l'incompréhension des directives et du nombre élevé de questions récurrentes sur le forum.
Aujourd'hui, je pense que le "public" est prêt à utiliser les directives.

Je ne connaissais pas cette directive. Avant je ne connaissais que par exemple: const pi=3.1416.
Mais c'est pratiquement ce que je fais avec mes loader.
Je remplace des raccourcis de commande par des codes complet. Je le fais d'ailleurs avec #include pour la fonction chain, vu que chain ne s'occupe pas de cette directive. D'ailleurs lorsqu'on a essayé de faire avec Klaus des pseudo dim_local, ou des label_local, c'est encore des modifications du fichier source.
Donc je ne vois pas la dificultée de compréhension de cette nouvelle directive, du moment qu'elle est expliquée, et Jean Debord, en a une très bonne:

Citation :

Le préprocesseur va alors scanner tout le source et remplacer systématiquement toute occurrence de la chaîne "Pi" par la chaîne "3.14159", exactement comme on le ferait avec un traitement de texte. C'est le résultat de tous ces remplacements qui sera compilé.

Si cette directive correspond à cela, alors tu peux l'implémenter sans problème. A nous d'expliquer ensuite à ceux qui ne comprennent pas.
Nota: il est évident pour moi, qu'on ne va pas faire une directive pour remplacer 100 lignes sur une seule commande.

je confirme, que ce soit #const NomDelaConstante ValeurDelaConstante
ou const NomDelaConstante=ValeurDelaConstante
ça me parrait très clair.
Après, il faut ajouter des messages d'erreur si l'on cherche à modifier la valeur dans le programme (genre: Erreur: vous cherchez à modifier la valeur du constante ligne XXX)

Je pense qu'un pourrait traiter les constantes comme les variables système: en READ_ONLY sans message d'erreur en écriture. Voir l'exemple suivant:

Code:

number_click = 3
message str$(number_click)
end

Puisqu'on parle de constante
perso, la syntaxe du C me conviens parfaitement

Code:

#CONST Pi 3.1415926

Le symbole '=' représente une affectation, chose qui ne me parait pas propre au niveau sémantique dans le cas d'une définition de constante.

De même, pour l'histoire du READ_ONLY, ce n'est pas normal de pouvoir écrire NUMBER_CLICK = 3 sans déclencher d'erreur...(pour moi c'est un bug)

Si la syntaxe du C est trop perturbante pour certains, on peut peut être définir une constante de cette manière:

Code:

 #CONST Pi AS 3.1415926

puisqu'après tout, c'est bien d'un ALIAS que l'on parle...
(Je préfère quand même la 1ere version)

Mais comme dis jean debord, c'est à Jack de faire son choix...

Le choix de Jack est fait, puisque c'est seulement désactivé.

Exact !

Mais bon, comme ce n'est pas actif, ça peut toujours être modifié ... en tout cas, moi je trouve la syntaxe ci dessous très claire:
#CONST Pi AS 3.1415926
#CONST Autheur$ AS "Nardo26"
#CONST Nb_ViesInitiales AS 5

Je vais jeter un pavé dans la mare, mais personnellement ça ne me gêne pas spécialement d'écrire
DIM Pi: Pi = 3.1415926

Et que dites-vous de cette syntaxe

#Const pi VALUE 3.14159
#Const Facteur VALUE pi/180
#Const Nb_Max VALUE 10
#Const Nom_Fichier VALUE "D:\Panoramic\exemple.bas"


On est tous d’accord sur l’utilité de déclarer des constantes : peu importe la syntaxe qui sera utilisée !

Je suis d’accord avec toi JL35.

Mais pouvoir déclarer des constantes pousse un peu plus certains programmeurs à utiliser des constantes plutôt que des variables.

Dans certains codes on voit, par exemple ceci :

Code:

Dim Tableau(10)
…
….
For i% = 1 to 10
    Tableau(i%) = …
…

Supposons que dans ce programme, on utilise plusieurs fois le Tableau ainsi déclaré ; supposons aussi qu’un jour on se rend compte que notre tableau devrait avoir une autre valeur comme dimension (13 au lieu de 10) : on serait obligé de changer la dimension du tableau dans plusieurs endroits du programme, avec toujours le risque d’en oublier !
Or, si on avait pris la bonne habitude de déclaration des constantes, la correction du programme se fait simplement en modifiant la valeur de la constante.
Le code précédent devrait être comme ceci

Code:

#Const n = 10 : ‘ Ou autre syntaxe !
DIM Tableau( N)
…
…
For i% = 1 to n
…

Il est toujours possible de coder ainsi sans déclaration explicite de constantes en utilisant

Code:

Dim n : n = 10
Dim Tableau(n)
…

Pour moi : utiliser toujours des constantes tant que faire se peut : la maintenance de vos programmes sera facilitée.
User des constantes sans craindre d’en abuser !

Tu as raison dans l'absolu et dans la logique, d'accord pour utiliser une variable/constante le plus possible, mais enfin écrire Const n = 10 au lieu de n = 10 je n'y vois pas un progrès phénoménal quand on a un minimum de discipline.

Il y a un double motif pour l'utilisation des constantes:
1. une constante est protégée en écriture, ce qui évite des problèmes lors d'une affectation de valeur par mégarde
2. une constante, suivant son mode d'implémentation, accélère le traitement à l'exécution, puisque toutes les occurrences d'une constante sont remplacées par sa valeur, par le compilateur. J'imagine que Jack a prévu de faire cela de façon similaire au traitement de la directive #INCLUDE, c'est-à-dire juste AVANT le début de l'exécution proprement-dite.

Je pourrais proposer une autre syntaxe:

Code:

#CONST
pi=3.14159
auteur="Klaus"
tableau%(10)=3,7,12.3,0,0,4,117.99,2,3,4
mois$(4)="Janvier","Février","Mars","Avril"

Bonjour,
Elle s'arrête quand ta déclaration de constante Klaus, avec la syntaxe que tu proposes ?
Car si j'écris:

Code:

DIM auteur$
#CONST
pi=3.14159
tableau%(10)=3,7,12.3,0,0,4,117.99,2,3,4
mois$(4)="Janvier","Février","Mars","Avril"
auteur$="Klaus"

Il se passe quoi pour auteur$ ?
il manque peut être un #END_CONST (comme la directive #ENDIF en C) ?

C'est évidemment un oubli de ma part:

Citation :

#CONST
pi=3.14159
auteur="Klaus"
tableau%(10)=3,7,12.3,0,0,4,117.99,2,3,4
mois$(4)="Janvier","Février","Mars","Avril"
#END_CONST ou simplement #END

C'est vrai que cette syntaxe de déclaration en bloc est sympa mais pas vraiment en accord avec la syntaxe actuelle.
sinon on aurait pu écrire aussi:

Code:

#CONST
toto = 12
pi = 3.1415926
auteur$="Klaus"
#END
#DIM
machin,truc,bidule$
titi(10)
#END

Exact. De toutes façons, on ne fait que lancer des ballons dans l'air, et c'est à Jack d'en attraper un s'il le souhaite. Je suis sûr qu'il a déjà une idée précise de l'implémentation de cette fonctionnalité, d'autant plus qu'il a dit que cela a déjà été fait, seulement pas mis en ligne estimant que la communauté n'était pas mûre pour cela.

Pour la part, j'aime bien la notion de constantes, et j'essaie de les simuler dans mes programmes par des variables déclarées séparément des autres variables. Mais ce n'est qu'une béquille. On verra bien ce que Jack nous dévoilera lorsqu'il le jugera utile.

On peut également imaginer ceci :

Code:

DIM I%,A$
#CONST
LET pi = 3.14159
LET Auteur$  = "Personne"
LET Radian = Pi/180
...
I% = 1 : A$ = "Hello" : ' ce sont des variables puisqu’elles ne sont pas précédées par LET.

On peut imaginer d’autres formes de syntaxes et Jack a certainement son idée.
L’essentiel c’est qu’il semble que la majorité est pour la possibilité de déclaration des constantes.
WAIT AND SEE !

Sur le premier post que j'ai mis à la suite de Jean Debord, j'avais essayé de retouver le sujet qu'on avait abordé concernant les dim_local et sans succès. En cherchant sur Google une réponse pour un sujet particulier, j'ai retrouvé ce sujet qui n'était d'ailleurs pas en rapport avec ce que je cherchais. Mais il y a de la mayonnaise dans la recherche de Google.
https://panoramic.1fr1.net/t1266-variables-locales-et-dim-dynamique
Je pensais que c'étais un sujet de discutions ou d'aide.