problème avec les appels Gosub

bonjour à tous.
Je rencontre un problème avec l'appel de sous-routine (Gosub - Return)
Bien sur j'ai effectué pas mal d'essai, mais je n'ai pas résolue le problème.

A partir d'un clique sur un objet, je me dirige normalement vers une s-routine. Pas de problème. Cependant, lorsque cette s-routine renvoie vers une autre, je ne peux effectuer que 5 appels de la 1ère routine? j'ai alors le message suivant : " Too Many Nested Gosub line xxx qui fait référence à l'appel de la seconde routine.....

Exemple simplifié :

Code:

001 REM *************************************
002
003 label premiere_s_routine
004 label deuxieme_s_routine
005
006 button 1
007 on_click 1, premiere_s_routine
008 end
009 REM *************************************
010
011 premiere_s_routine:
012
013        gosub deuxieme_s_routine
014
015 return
016
017 deuxieme_s_routine:
018        print "coucou"
019 return

Après 5 appels de " première_s_routine "

j'ai le message " Too Many Nested Gosub line 013 "

quand est-il.

Il s'agit d'une des limitations volontaires de la version d'essai. Voir le manuel de référence:

Citation :

18 - VERSION FREEWARE (GRATICIEL)

Dans cette version freeware de PANORAMIC, toutes les fonctionnalités sont actives, mais il y a quelques limitations:

- Nombre d'objets système: 35
- Nombre d'objets 3D: 25
- Nombre d'objets SPRITE: 20
- Nombre de variables utilisateur: 40
- Nombre de labels: 40
- Nombre de IF / END_IF: 40
- Nombre de WHILE / END_WHILE: 40
- Nombre de REPEAT / UNTIL: 40
- Taille maximale de tableau de variable: 200
- Nombre de fichiers texte ouverts simultanément: 5
- Nombre de fichiers EXCEL utilisés simultanément: 2
- Profondeur de boucles "FOR" emboîtées: 10
- Profondeur de GOSUB emboîtés: 5

Merci JL35, j'avais vu cette limitation. Mais dans mon cas ci-dessus, il s'agit, si j'ai bien compris, non pas d'emboitement, mais d'appel.
Je pense que l'emboitement consiste à ce qu'il y ait un empillage de 5 Gosub
du genre

Code:

  gosub A1

a1: 
  gosub A2
return

A2:
 gosub A3
return


A3:
  gosub A4

return

A4:
 
 
return

?????

Ton code n'est pas très clair, mais il semble que tes sous-programmes soient imbriqués l'un dans l'autre, c'est à dire qu'on appelle un deuxième sous-programme depuis l'intérieur d'un premier, et ainsi de suite, et qu'on arrive à la limite d'imbrication de 5.
C'est à dire qu'on lance un 6ème GOSUB alors qu'il y a déjà 5 RETURN en suspens...
Enfin, à première vue...

Edit: tel qu'il est, ton code devrait marcher, s'il n'y a qu'un appel et retour de sous-programme à l'intérieur d'un autre...
Je vais essayer, pour voir si je peux reproduire ce que tu constates.

ReEdit: eh bien bravo Vaillant, je crois bien que tu as mis le doigt sur une belle anomalie ! si on déroule le code suivant (quasiment identique au tien):

Code:

label sp1
label sp2
dim cpt1, cpt2
cpt1 = 0: cpt2 = 0
button 1: left 1, 200
caption 1,"Cliquez"
on_click 1, sp1
end

sp1:
print "cpt1="+str$(cpt1)+" cpt2="+str$(cpt2)
cpt1 = cpt1 + 1
print "Entrée dans le s/p 1"
gosub sp2
print "retour du 2ème s/p": rem on ne passe jamais ici
cpt1 = cpt1 - 1
return

sp2:
cpt2 = cpt2 + 1
print "s/p 2, appelé par le s/p 1"
cpt2 = cpt2 - 1
return

on s'aperçoit que le return du sp2 revient directement sur le end, on ne repasse jamais sur le RETURN du sp1 et le compteur cpt1 continue à s'incrémenter, et au bout de 5 fois, patatras ! ça plante.
Il n'y a plus qu'à soumettre ça à la sagacité du grand maître.

encore merci JL35.

C'est pas toujours facile de s'expliquer, mais tu a parfaitement compris le hic.

En effet, j'ai commencéà programmer une base de données pour une Bande Dessinées anciennes (Free). La première partie de ce programme a été développée l'an dernier, sous RapidQ. Ayant découvert Panoramic et ayant été emballé, j'en ai profité pour ajouter un deuxième module programmé avec ce langage. Je suis arrivé à résoudre les limitations tels que l'ouverture de fichiers. Mais je bute depuis plusieurs jours sur l'appel de s-routines, qui me sont nécessaires pour éviter les redondances. Et là, si je veux par exemple sauvegarder les saisies en cours, je suis limité à 5 fois....
Et bien sur j'ai le même problème pour d'autres opérations.

Il y a presque toujours des solutions pour contourner les problèmes, plus ou moins élégantes...
Par exemple tu pourrais intégrer le code de ton deuxième sous-programme en dur dans le premier ? c'est moins modulaire, mais ça pourrait débloquer la situation, en attendant mieux ?

C'est ce que j'ai fait, et ça m'a solutionné un autre problème, tout est bien qui fini bien.

Pour le nombre de fichier ouvert, j'ai résolu le problème de la manière suivante, si ça peut intéressé....

Si on a plus de 5 fichiers à ouvrir.....?

Et bien, j'en ouvrir 1 en lecture par exemple dans une routine du genre

Code:

sous_routine_lecture:

    if monchoix% = 1 then nom_de_fichier$ = "premier_fichier"
    if monchoix% = 2 then nom_de_fichier$ = "deuxième_fichier"
    if monchoix% = 3 then nom_de_fichier$ = "troisième_fichier"
    if monchoix% = 4 then nom_de_fichier$ = "quatrième_fichier"
    etc..........

    open_file_read 1, nom_de_fichier$

    if monchoix% = 1             
          REM ici les lignes de programmation pour lire "premier_fichier"
    end_if

    if monchoix% = 2
          REM ici les lignes de programmation pour lire "second_fichier"
    end_if

    if monchoix% = 3
          REM ici les lignes de programmation pour lire "troisième_fichier"
    end_if

    if monchoix% = 4
          REM ici les lignes de programmation pour lire "quatrième_fichier"
    end_if

    etc.......

    file_close 1
RETURN

je l'utilise et c'est très efficace.


Il suffit de créer une autre routine pour l'écriture, et le tour est joué.
Sympa non.

Une suggestion: plutôt que de multiplier les IF tu pourrais utiliser la structure:

Code:

SELECT CASE monchoix
  CASE 1
      traitement 1
  CASE 2
      traitement 2
  etc...

END SELECT

Tu as tout à fait raison JL35.
J'ai repris mon exemple, car dans mon programme, j'ai besoin de passer du choix 1 au choix 3, pour un autre fichier dans la même foulée. Donc, je dois utiliser un Goto sur le label de la routine. Mais c'est vrai est beaucoup plus élégant.

A pluche

Citation :

C'est à dire qu'on lance un 6ème GOSUB alors qu'il y a déjà 5 RETURN en suspens...

C'est exactement à ce moment qu'apparait l'erreur qui indique qu'il y a plus de 5 sous-programmes imbriquées.

En examinant l'exemple de JL35 sur les 2 sous-programmes indiqués:

Citation :

print "retour du 2ème s/p": rem on ne passe jamais ici

Eh bien, je suis d'accord, on devrait pourtant exécuter cette ligne.

Si j'exécute ce programme, repris de l'exemple de JL35 et simplifié, on a une erreur manifeste:

Code:

label sp1
label sp2

button 1: left 1, 200
caption 1,"Cliquez"
on_click 1, sp1
end

sp1:
print "Entrée dans le s/p 1"
gosub sp2
print "retour du 2ème s/p": rem on ne passe jamais ici
return

sp2:
print "s/p 2, appelé par le s/p 1"
return

Mais si j'exécute celui-ci, qui a exactement la même structure: (attention il est difficile de terminer son exécution, mais il est donné pour l'exemple)

Code:

label sp1
label sp2
label attendre

button 1: left 1, 200
caption 1,"Cliquez"
attendre:
if clicked(1)=1 then gosub sp1
wait 100:goto attendre
end

sp1:
print "Entrée dans le s/p 1"
gosub sp2
print "retour du 2ème s/p": rem on ne passe jamais ici
return

sp2:
print "s/p 2, appelé par le s/p 1"
return

On n'a pas d'erreur.

Ce qui ne fonctionne pas, c'est le fait d'appeler un sous-programme dans le traitement d'un événement.
En effet, le traitement d'un événement, lorsqu'il arrive à son terme (RETURN), ne renvoie jamais à une ligne de code. Car le traitement des événements est complètement indépendant du programme principal. C'est le principe de la programmation événementielle: on programme ce qui doit arriver lorsqu'un événement arrive sur un objet, et de manière indépendante du reste.

Mais on devrait pouvoir appeler un sous-programme dans un traitement d'événement...
Je n'avais pas prévu ce cas de figure. Je vais y remédier.