Petite question à Klaus

J'ai remarqué dans une de tes sources que tu avais incluse tes lignes de déclaration d'objet dans des subs.

Est ce une habitude de programmeur ou y a t il un intérêt autre ?

Précision, c'était dans le source pour formatage des nombres ou l interface est prise dans un sub.

Bonsoir, Ygeronimi,

Il n'y a aucune nécessité, et aucune utlité sur le plan fonctionnel, d'inclure les déclarations des objets dans un sous-programme. Je fais cela afin de rendre mon programme plus modulaire. Ainsi, ma routine principale (du début jusqu'à l'instruction "end") est courte et facilement lisible. Les noms des sourprogrammes expliquent directement leur usage ce qui sert de documentation. J'ai ainsi isolé la partie définition de la form du reste du programme pour pouvoir le maintenir plus facilement. J'essaie de procéder ainsi le plus souvent possible; cela permet aussi d'extraire ces parties facilement dans un autre fichier pour les traiter à part. Le but final est bien sûr de les garder dans ces fichiers à part et de les inclure dans le programme d'origine par une directive #INCLUDE. Dans le programme de démonstration que tu cites, je ne suis pas allé jusque là pour réduire le nombre de fichiers à distribuer, mais l'idée est bien là: produire un programme modulaire relié par des directives #INCLUDE.

Ceci dit, c'est ma technique personnnelle que j'emploie depuis très longtemps dans d'autres langages de programmation. Si un jour tu as un programme qui fait 2.000 ou 15.000 lignes de code (oui, oui, ça arrive...), alors tu seras heureux de pouvoir travailler avec de petits modules réalisant chacun une fonction bien définie, au lieu de farfouiller dans un seul fichier source énorme. Et je ne te parle même pas des risques de fausse manip, en particulier avec des fonctions comme "recherche et remplace" etc.

Entièrement d'accord avec toi Klaus.
Dommage même qu'on ne puisse aller plus loin avec des modules indépendants (avec leurs propres déclarations de variables et étiquettes indépendantes les unes des autres) qui rempliraient des tâches bien précises, à inclure à la demande dans un module principal.
Le véritable obstacle à ça c'est la déclaration des variables et étiquettes, contrainte qui n'existait pas en QBasic. Et ces déclarations sont communes à tout le module.

Merci bien pour ces explications .
Je me disais bien qu'il y avait un intérêt à cette mise en forme du code mais je préferai avoir une réponse claire de l 'auteur plutôt que des suppositions de ma part.

Cependant, je relève un ennui a à cette présentation qui demande un effort de mémoire régulièrement.
Je me suis appercu que dans certain cas, il nous faut une instruction if..end_if de plus pour pouvoir rappeler un form par un bouton.

au premier appel , pas de soucis le form se construit
on hide le form , tout va bien on le cache
mais pour son rappel, si on a pas intégré la condition où le form est existant mais seulement caché dans la fonction d'appel ...
Oups!.. "erreur l'objet existe déjà , impossible de le créer".

mais il est vrai que celà ne peut se produire pour le form 0.

Pour JL35:

En effet, des modules vraiment indépendants seraient très utiles. Mais alors là, c'est une autre paire de manches pour Jack: on aurait des sousprogrammes qui devraient être liés au programme appelant (ou au sousprogramme appelant) par une phase d'édition de liens (nommé "link" habituellement), avec résolution des symboles au moment du link, et cela exclut le mode d'exécution interprèté dans l'éditeur tel qu'il existe actuellement. Mais quelle puissance: on pourrait alors passer des paramètres en entrée et sortie d'un sousprogramme, écrire une fonction en Panoramic pour retourner une valeur, etc. Je crains bien que cela ne reste un voeu pieu enore pour on bon moment, n'est-ce pas, Jack ?

Pour Ygeronimi:

Je pense qu'une bonne pratique de programmation permet d'éviter l'écueil que tu mentionnes. En effet, si un objet (que ce soit une form ou un autre objet) doit tantôt être visible, tantôt invisible, selon les besoins de l'application, il faudrait créer cet objet dès le départ, le cacher aussitôt pour le réaffichier selon les besoins. On lui associe alors une variable d'état, contenant 0 pour "invisible" et 1 pour "visible". On peut alors très facilement conditionner l'instruction show par cette variable:

Code:

dim etat_form1%
form 1
hide 1
etat_form1% = 0


....


rem pour afficher la form 1
if etat_form1=0
    show 1
    etat_form1% = 1
end_if

rem pour cacher la form 1
if etat_form1=1
    hide 1
    etat_form1% = 0
end_if

D'ailleurs, cela me donne l'idée d'une suggestion d'amélioration que je vais poster dans la rubrique concernée.

Est-ce que j'ai bien saisi le problème que tu as évoqué ?

D'accord avec toi Klaus pour le fait que ça serait sûrement très difficile à Jack d'intégrer cette notion dans Panoramic, qui n'est pas fait dans cet esprit.
Ce serait autrement plus complexe que l'Include, avec comme tu dis une édition de liens dans la compilation.
Et je ne pense pas qu'on le voie jamais.
Mais bon, c'était un voeu pieux.

c ' est pourquoi dans mon carnet d'adresse ,et je le fait sur quasiment tous mes petits programmes maintenant, j ' utilise execute_wait pour des modifications de fichiers et je réinitialise le prog principal derrière pour tenir compte des nouvelles valeurs.
Plus de pb de form qui existe ou pas ni de d'effet visuels désastreux à l'ouverture quand on a plusieurs form hider au départ.
Je suis un peu têtu avec mon carnet d'adresse non....
en ce moment, j'essaie de lui ajouter une possibilité de skin.

Citation :

on pourrait alors passer des paramètres en entrée et sortie d'un sousprogramme, écrire une fonction en Panoramic pour retourner une valeur

Cela, c'est pour bientôt; et sans phase d'édition de liens.