Problème d'appel de SUB.

Bonjour.

L'appel de la sub suivante provoque l'erreur: nom de sub incorrect !

Je ne vois vraiment pas où se situe l'erreur.

Merci de votre aide.

Code:

sub enlever_arobaces(param1$, param4%)

    numero_ligne_courante%=param4%
    if tracage%=true% then print "'enlever_arobaces' appelé ligne "+str$(numero_ligne_courante%)

    msa$=param1$

    if left$(msa$,1)="@" then msa$=mid$(msa$,2,len(msa$))

    while true%=1
          zz99%=instr(msa$,"@")
          if zz99%=0 then exit_while

          msa$=left$(msa$,zz99%-1)+mid$(msa$,zz99%+1,len(msa$))
    end_while

end_sub

Bonjour,
J'ai eu le même problème sur mon sujet en cours qui concerne la hauteur effective de l'intérieur d'une fenêtre.
En fait il y avait une légère différence dans l'appel de la sub:
l'appel: determine_marges(obj1%,obj2%)
et la sub: sub determine_marge(obj1%,obj2%)
Vérifie si c'est le même nom.

Tu n'as posté que la procédure, pas son appel. Comme le dit Cosmos, le problème est dans la ligne qui fait l'appel. Voici quelques lignes de code qui appellent ta procédure. Tot marche parfaitement:

Code:

dim txt$
dim numero_ligne_courante%, tracage%, msa$, zz99%,true%
true% = 1
txt$ = "abc@def"
enlever_arobaces(txt$,0)
message "résultat: "+msa$
end


sub enlever_arobaces(param1$, param4%)

    numero_ligne_courante%=param4%
    if tracage%=true% then print "'enlever_arobaces' appelé ligne "+str$(numero_ligne_courante%)

    msa$=param1$

    if left$(msa$,1)="@" then msa$=mid$(msa$,2,len(msa$))

    while true%=1
          zz99%=instr(msa$,"@")
          if zz99%=0 then exit_while

          msa$=left$(msa$,zz99%-1)+mid$(msa$,zz99%+1,len(msa$))
    end_while

end_sub

cela peut aussi arriver si tu laisse un espace entre la dénomination et la première parenthèse.

Bon : Ma_Sub()

Mauvais : Ma_Sub ()

et de même lors de sa déclaration.

Eh oui, les problèmes de structure...

Pour la part, j'ai pris l'habitude de coder immédiatement la commande de fin pour une commande qui en requieet une, puis j'insère mon code entre les deux. Cela concerne:
IF...ELSE...END_IF
WHILE...END_WHILE
REPEAT...UNTIL
FOR...NEXT
SUB...END_SUB
etc

De cette manière, je suis relativement à l'abri de ces erreurs "techniques", aux fausses manipulations près. En effet, un couper/coller mal ajusté peut perturber la plus belle des structures.

Quand à moi je rajoute systématiquement une indentation dans le corps de la procédure...

Moi aussi je fais comme vous.
En plus, je sépare mes procédures par une ligne REM pleine d’étoiles (ou d’autres caractères).
Comme ça, un simple contrôle visuel permet d’éviter quelques oublis ou étourderies !
A chacun sa méthode.

Bonjour,
En regardant les nouvelles commandes que j'utilise pas encore, je me pose une question.
On a les appels avec return
les appels avec SUB
Un jour peut-être les fonctions.

Pour distinguer lors des échanges entre-nous les appels habituels par rapport aux sub, j'employais le mot: PROCEDURE. Ors je constate ceci:

Citation :

les sous-programmes (appelés aussi "procédures") :
On déclare un sous-programme par SUB, suivi de son nom et d'un ou plusieurs paramètres entre parenthèses.
Les paramètres déclarés sont locaux au sous-programme. Il peuvent avoir le même nom que des variables globales (déclarées par DIM).
On termine le code d'un sous-programme par END_SUB.
On appelle un sous-programme directement par son nom.
Pour déclarer un sous-programme sans paramètre, ainsi que pour l'appeler, on met des parenthèses.

S'il vous plait, aux pros, comment dois-je appeler un sous-programme habituels avec return par rapport aux procédures, que j'ai l'air moins con!
Le mot sous-programme étant un ici un terme générique pour tous ces appels.
Merci

Oui Cosmos tu as raison, il serait temps que l'on accorde notre vocabulaire....

Pour moi SUB/END_SUB et GOSUB/RETURN entrent tout les deux dans la catégorie des Sous-Programmes.

Une procédure (à mon sens) peut effectivement être appelée des 2 manières.

Si je me trompe, corrigez-moi.

A+

PS: je propose Sous-programme ou Procédure par Label ou par Sub...

Je ne suis pas d'accord, Jean-Claude.

Pour moi, un "sous-programme" est appelé par une commande spécifique, quelque soit le langage de programmation. Dans notre cas, c'est GOSUB, dans d'autres langages, cela peut être CALL ou autre. Mais il y a toujours un mot-clé qui signale "je veux appeler un sous-programme dont ne nom suit". Un sous-programme se termine TOUJOURS par un RETURN.

Une procédure est appelée directement par son nom, SANS passer par un mot-clé spécial genre GOSUB ou CALL. En fait, la procédure définit son propre mot-clé qui peut être utilisée à la place d'une commande Panoramic. Il y a là une différence au niveau sémantique du langage.

Certes, au final, les deux systèmes conduisent à exécuter un ensemble cohérent de lignes de code, regroupées par des repères début/fin, et l'exécution se poursuit à l'instruction qui suit l'appel. Mais il y a une différence fondamentale: par la nature même de l'encapsulation d'un sous-programme (label:...RETURN), on peut avoir des lignes de code qui précèdent le label d'un sous-programme, et leur exécution se poursuit en entrant dans le sous-programme ! Exemple:

Code:

label sub1
message "ici, c'est le code normal"
sub1:
  message "ici, c'est le sous-programme"
  return

Cela permet de faire des sous-programmes avec plusieurs "points d'entrée": il suffit de placer plusieurs labels dans le code et faire un GOSUB de n'importe lequel de ces labels, en fonction des besoins. C'est une technique très utilisée dans d'autres langages comme Fortran par exemple: on y déclare des points d'entrée par ENTRY suvi du nom, et cela permet de rendre les sous-programmes plus souples et modulaires.

Ceci n'est pas possible avec une procédure. Une procédure n'a qu'n seul point d'entrée: celui déclaré par la commande SUB. On ne peut pas mettre un label dans une procédure et vouloir faire un GOTO, GOSUB ou ON_xxx sur ce label. Cela n'a pas de sens.

Maintenant, je te l'accorde, et avec tout le respect que j'ai pour le travail et le dévouement de Jack, les mots-clé pour introduire et terminer une procédure sont très mal choisi, et je pense que la confusion vient de là. Il aurait mieux valu choisir

Code:

PROC MaProcedure(par1,par2,...)
...
END_PROC

On n'aurait peut-être même pas cette discussion puisque les choses serait claires. Petit clin d'oeil à Jack, si je puis me permettre ?

Merci Klaus, donc on appel ici comment?
procédure ou sub, et sous_programme pour les gosub/return?

Peut-être si c'est pas trop de travail, Jack pourrait faire un doublon de commande: SUB ou PROC, ce qui permettrait d'être dans le protocole de la procédure, et de ne pas reprendre tout ce qui est fait, et on pourrait ainsi appeler: PROCEDURE pour ce qu'on appelle les sub, et SUB pour sous-programme. On se comprendrait.
Cela fait un boulot de plus à Jack, mais je ne crois pas que ce soit terrible. Mais il est évident que je ne suis pas dans son code, et ce que je dis est de l'extrapolation!
C'est idiot d'emmerder Jack avec cela. Qu'il fasse ses commandes pour ses jeux comme il le veut.

Salut tout le monde.

Je suis d’accord avec toi, klaus.
J’ajoute ceci :
Lorsqu’on décide de faire un programme un peu plus important que :

print "salut"
end

on est vite amené à décomposer ce programme (ayant une certaine complexité) en sous-programmes de complexité moindre.
Puisqu’on décompose un programme, il est légitime d’appeler ces subdivisions des sous-programmes : terme général qui manque de précision !

En général et selon le langage de programmation utilisé, on distingue deux sortes de sous-programmes (appelés également des routines ou même des sub-routines) : les sous-programmes qui réalisent une tache quelconque mais bien précise et parfaitement définie et les sous-programmes qui, en plus, doivent impérativement retourner une valeur et une seule.
Les premiers sont appelés des procédures , les seconds des fonctions.
Ces procédures et fonctions sont appelées à partir du programme principal (ou des autres sous-programmes) par leurs noms en leurs transmettant éventuellement un ou plusieurs paramètres sur lesquels elles travaillent.

En PANORAMIC, on dispose de deux sortes de sous-programmes : ceux déclarés par un nom_label et se terminant par RETURN et ceux qui sont déclarés par SUB et se terminent par END_SUB.
Les sous-programmes déclarés par nom_label sont appelés par GOSUB nom_label sans pouvoir rien leur transmettre comme paramètres.
Je pense (et c’est mon point de vue strictement personnel) qu’on peut leur donner le nom générique de sous-programme.
Par contre les sous-programmes déclarés par SUB seront appelés des procédures .
Les futures sous-programmes qui devront retourner une valeur et qui seront déclarées par FNC et se terminent par END_FNC (ou d’autres mots réservés) seront appelées des fonctions.

Je pense que dans le futur, la déclaration des sous-programmes par nom_label sera obsolète et si PANORAMIC gardera GOSUB et RETURN c’est uniquement dans un souci de compatibilité avec des programmes anciens.

Voila, c'est mon point de vue, c'est tout!

...Et c'est déjà pas mal

Donc on emploiera: sous_programme pour : label/return, et procédure pour les sub/end_sub.
On est tous d'accord?

Entièrement. C'est la terminologie que j'utilise.

Moi çà me va, l' essentiel est de parler de la même chose .

Bon, maintenant c'est clair, On emploi le terme Procédure pour un SUB et Sous-Programme pour les appels à des LABEL(s)
Ainsi nous parlons tous la même langue. Cette convention me va très bien...

Merci A+