[r]Y aurait-il une limite dans le nombre de sub?

Désolé de revenir.
Ce matin j'ai eu ce problème sur une sub que j'ai ajouté, et je n'ai pas pu faire marché le programme avec un message d'erreur sur un nom de sub que je savais correct. Bon je l'ai transformé en sous-programme.

Depuis pour finaliser l'ajout de contrôle sur les images, j'ai rajouté des boutons, un check, un edit et un alpha.

J'ai fait les procédures et une fois terminé, je relance le programme, et je me retrouve avec cette erreur sur une sub qui fonctionnait avant, dont le nom est correct.

Là il y a bien un problème.
A savoir que j'ai redémarré l'ordinateur, et fait aussi les essais avec le programme compilé.

Combien j'ai de sub? je compterai ce soir, car là j'ai pas le temps.

Bonjour Cosmos.

Je pense que ton programme entre directement dans la sub, sans passer par un appel direct.
Il manque certainement un 'end' avant le 'sub'.

Le message d'erreur que tu mentionnes apparaît si on enlève le 'end' du code ci-dessous.

Bon courage.

Code:

list485_image()
end

sub list485_image()

end_sub

Bonjour,
Non pas du tout. Ce programme fonctionne depuis x temps. J'apporte des améliorations, ou des corrections.
Ce matin, c'était à la ligne 2748 pour la même erreur de nom de sub, en décomposant une sub plus haut que la ligne 2748, pour y avoir plusieurs appels. Donc j'ai décomposé une sub en deux, et c'était la deuxième sub qui bloquait sur un problème de nom tout à fait correct. Des sub j'en ai avant. C'est depuis que j'en rajoute que j'ai ce problème. De plus la sub que j'ai montré plus haut, elle fonctionne depuis hier (en rapport avec le sujet que j'ai mis sur un clic).

Bon, je viens de faire l'essais d'inclure le contenu de la sub dans la procédure d'appel de la sub.
En fait l'appel de la sub était d'avoir des variables locales, donc normalement tout doit pouvoir être intégré dans le sous-programme.

Résultat, après contrôle d'avoir fait les choses correctements (déclarations...
list index out of bounds(-1)

Jack ne dit pas tout. Normalement ce n'est que pendant la lecture des déclarations. La procédure n'est appelée que bien plus tard, après différents appels.

Il n'y a pas d'oubli comme end_sub remplacé par return. La sub est complètement effacée.

Je suis plutôt déçu d'en être à la fin, et devoir renoncer, et pas d'explication.
Je sais bien que ce que je fais ce ne sont pas des jeux, donc à notre époque où il n'y a plus que cela, cela représente évidemment pas d’intérêt. Drôle d'époque! Il y a quarante ans c'était l'inverse.

Je croix que l’erreur (150) Nom de SUB incorrect. Line : xxx est provoqué dans deux cas qui se ressemble d’ailleurs.
1er cas : Entrée directe dans une SUB sans appel
Exemple :

Code:

error_french
sub1()
' end
sub sub1()
    print "Sub1 en cours .."
stop
end_sub

2ème cas :
Lorsque, dans une SUB, il manque END_SUB et il existe une autre SUB
Exemple :

Code:

error_french
sub1()
sub2()
 end
sub sub1()
    print "SUB 1"
' end_sub

sub sub2()
    print "SUB 2"
end_sub

@Cosmos70
Il est fort probable que (étant donné la longueur et la complexité de ton programme) tu as oublié quelque part dans une SUB, un END_SUB.
Quant à savoir s’il y a une limite dans le nombre de SUB, je croix que non (à part bien sûr la capacité de l’ordi)

EDIT :
Dans ton dernier post, tu indiques un list index out of bounds
Cette erreur est provoqué lorsqu'il manque un END_SUB
Vérifie que toutes les SUB ont leur END_SUB.
Je suis presque sûr que le problème réside dans un END_SUB manquant

Oui Papydall, je connais le problème sur cette erreur.

J'ai passé un bout de temps pour regarder tout le code, et je n'ai encore rien trouvé d'anormal.

J'ai repris un ancien programme pour tout indenter comme il faut, et je déplace les procédures qui sont dans le gui, protégé pour les remettre dans le code de fonctionnement.

Il y a encore du travail, et il me faudra encore du temps.

Bien voila!

C'est mon programme qui est en cause. J'ai remis de l'ordre partout.
J'étais persuadé que ce n'étais pas un problème de codage de sub, et c'était pas le cas.
C'est un end_if qui était très mal placé. Je pense même qu'il y en avait un deuxième mais comme il y a eu beaucoup de déplacement, ce serait dure d'être affirmatif. J'ai bien déplacé une cinquantaine de sous_programmes.

Je marque ce poste comme résolu, et remercie Papydall et Pedro pour leurs interventions.

Bien, voila.
Je suis content pour toi et aussi content que l’erreur n’est pas due à Panoramic ce qui nous réconforte tous !

Jongler entre plusieurs milliers de lignes de code demande beaucoup de présence d’esprit et de concentration.

Cosmos70 a écrit:

Je suis plutôt déçu d'en être à la fin, et devoir renoncer, …

Surtout pas. Renoncer n’est pas la solution !. Persévérer   oui !

Tu verras Papydall, ça arrive de temps en temps à Cosmos. Il pense baisser les bras, il laisse passer un peu de temps et il réattaque sous un autre angle... C'est tout Cosmos ça...

Je suis content aussi que le problème ne soit pas du à PANORAMIC.
Pour répondre au titre de ce post, non, il n'y a pas de limites au nombre de SUB.

L'erreur 150 apparait au début, bien avant l'exécution du source, lors de l'analyse de la structure du source, lorsque le nom d'un SUB n'est pas syntaxiquement correct.
Dans le cas que montre cosmos70, le nom list485_image() semble correct. Bizarre ...
Je pense que la structure du source n'étant pas bonne, PANORAMIC se perd dans l'analyse et annonce un problème de nom de SUB alors qu'il devrait annoncer un autre problème. Mais ce n'est qu'une supposition.
Il faudrait, comme toujours, un exemple simple d'une dizaine de lignes maximum pour que je puisse analyser le problème.

Bonjour Jack.

Panoramic n'est pas en cause. Il y avait un problème de structure.
Il n'apparaissait pas, mais je pense qu'il y a un moment que c'était le cas, mais que des procédures n'étant plus appelée depuis un moment, et l'erreur n'était pas présente.

J'ai compté 114 sous-programmes pour l'instant, et 80 procédures.
Le fait est que lorsque j'ai commencé le programme, je ne savais pas encore comment j'allais m'y prendre, et j'avais en plus des lacunes en html pour faire celui-ci. Donc des modifications parfois importantes.

J'ajoute qu'en ce qui concerne Panoramic, je trouve qu'il y a eu une très nette amélioration dans l'analyse du source, par rapport à un ou deux ans. Moi qui est tendance à aller aux extrêmes dans les codages, je dis qu'il y a une amélioration dans le parser.