Passage de paramètres pour un tableau

Question

J'avoue avoir des difficultés à comprendre le passage des paramètres dans le cas des sous programmes (procédures ou fonction). La portée des variables est locale: on n'a pas le choix. Je 'ai du mal à comprendre pourquoi il faut changer le nom des variables que l'on passe dans un sous-programme appelé. J'écris une macro qui possède un grand nombre de variables, ce n'est pas facile de s'y retrouver bien que je commente allègrement, mais ça complique les choses de donner deux noms de variables différents pour une même valeur, que je dois d'abord traiter puis récupérer dans le programme appelant. Et si j'ai un programme qui appelle un sous-programme qui appelle un sous-programme qui appelle un sous-programme qui appelle un sous-programme qui appelle un sous-programme qui appelle une sous-fonction: Si je veux récupérer le résultat de ma fonction en bout de chaîne dans le tout premier programme principal, je suis obligé de passer autant de fois les paramètres qu'il y a de sous-programmes avec autant de noms de variables différents ? Je maîtrise mal les sous-programmes, ce qui me pousse à créer des macros indépendantes que j'appelle. Quel est l'avantage ou l'inconvénient de créer des macros différenciées et de faire appel à elles si ce sont des procédures et dans le cas des fonctions de stocker la valeur retournée dans une variable publique ? ce qui me gêne, vraisemblablement parce que je n'y suis pas habitué, c'est que je n'arrive pas bien à lire les codes avec les arguments et paramètres des appels de fonctions et je dois faire une gymnastique terrible pour retrouver quelle variable fait quoi. J'ai lu des cours et des tutos, mais bon... Si vous avez des liens pour des explications ras-la-moquette pour des limités comme moi, ça m'intéresse... Merci d'avance. Bonne après-midi...

paritec · Answer

Il n'est pas obligatoirement nécessaire de changer de nom de variable si tu as une variable public, tu peux l'utiliser dans toutes tes macros sans soucis, et en ce qui concerne les macros spécifiques à une action, c'est pour ma part bien mieux, et surtout bien plus lisible et facile à modifier a+ Papou...

MFerrand · Answer

Pourquoi donc ? Au niveau procédure les variables sont locales, elles n'existent que durant l'exécution de la procédure. Exception les variables déclarées avec le mot clé Static, dont la valeur est conservée entre deux exécutions de la procédure. Au niveau module, les variables ont une portée à l'intérieur du module, elles peuvent être utilisées par toute procédure du module. Déclarées avec le mot clé Public, leur portée s'étend au projet, elles deviennent accessibles de tous les modules. Si le module est privé, une variable déclarée Public dans ce module est accessible par : NomModule.NomVariable Il en et de même si des variables sont déclarées avec le même nom dans des modules différents (mais ceci est à éviter...) Les variables sont privées par défaut (déclarées avec Dim). Elles sont publiques si déclarées avec Public. Et les variables locales acquièrent une longévité si déclarées avec Static. On n'utilise pas Private pour les variables (pas de raison !) Cela c'est un peu à éviter car on finira par saturer la mémoire et planter Excel... Programme impliquant le plus souvent un ensemble de procédures, parlons plutôt Procédures. En VBA tout le code exécutable doit être inclus dans des procédures. En dehors, ne peuvent figurer que des déclarations, qui doivent être placées avant les procédures dans les modules. Les deux types principaux de procédures sont Sub et Function. Elles fonctionnent de la même façon, ce qui différencie les Function c'est qu'elles peuvent renvoyer un résultat, dès lors que dans la fonction figure une ligne de code : NomFonction = résultat On récupère ce résultat en utilisant la fonction à droite d'un signe égale, pour l'affecter par exemple à une variable. Mettre en place des procédures que l'on appelle tour à tour, chacun accomplissant une action déterminée, est en principe mieux qu'avoir une seule procédure, censée tout faire et dans laquelle on se noie souvent. C'est ce qu'on appelle programmer de façon modulaire. Cela permet souvent d'éviter des répétitions que l'on aurait dans une procédure plus longue en pouvant appeler plusieurs une seul proc. modulaire. Ou entre deux procédures auxquelles on peut faire appeler le même procédure modulaire. On gagne en volume de code, mais généralement aussi en rapidité d'exécution. Mais plutôt que la chaîne d'appel que tu indiques, mieux vaut avoir : Proc. principale =&gt; appelle Proc. secondaire1 =&gt; appelle proc. secondaire2 =&gt; appelle proc. secondaire3 =&gt; récupère valeur renvoyée par fonctionx etc. Ainsi, on n'a que 2 proc. en cours en même temps, alors que dans la chaîne d'appels successifs en cascade, toutes restent en cours. Je n'ai pas compris ce qui te posait problème dans les paramètres passés aux procédures, ni s'il s'agissait des paramètres des procédures que tu crées ou des paramètres des propriétés et méthodes que tu utilises dans le code. Cordialement...

paritec · Answer

Re Pipou64 le forum oui c'est sur que ce n'est pas la peine de l'utiliser si ton code est fait proprement et moi perso je ne l'utilise jamais pour apprendre le VBA en 5 jours là ???? !!!!!! bonne soirée Papou...

MFerrand · Answer

Il est recommandé de les déclarer et de les typer autant que possible. Cela fiabilise le code et le rend plus rapide... Utiliser ou non l'option Explicit est une question de goût... Si tu as pris l'habitude de déclarer systématiquement, tu peux t'en passer. Pour ma part, je n'aime pas l'avoir... et cela peut s'avérer utile pour coder une proc de test temporaire afin de vérifier un point, je m'évite d'écrire des déclarations de varaibles courantes que je vais effacer quelques minutes plus tard (par contre si la déclaration peut avoir une incidence sur le déroulement, je déclare même dans un teste temporaire...) Pour les variables objet il y a un intérêt évident à les type avec le type d'objet souhaité. En tapant un point après un nom de variable déclarée Worksheet ou Range, l'assistant VBA affichera la liste des propriétés et méthodes afférentes, cela aide... On ne le peut cependant pas toujours, avec des objets dont le type est fluctuant, par exemple des objets Shapes, reconnus comme Shape une fois finalisés mais pas en cours de construction...Pour pouvoir utiliser la variable durant le processus, on est alors obligé de la déclarer objet générique. Variant est le type par défaut. Quand on ne type pas, c'est Variant. Inutile donc de s'attarder à typer Variant... C'est parfois utile (tableaux accueillant plusieurs types de données, variable transformée alternativement en tableau ou chaîne texte avec Split et Join , etc.) ou même obligatoire (variable utilisée pour parcourir un tableau avec For Each, qui doit être de type Variant). Noter aussi que seule une variable de type Variant peut prendre la valeur Empty (on peut la tester alors avec IsEmpty) de mêm qu'un argument optionnel d'une procédure que l'on veut pouvoir tester avec IsMissing doit être de type Variant. Contrairement à la façon dont procède l'enregistreur, le passage d'arguments "normal" est par position (je me souviens même avoir vu quelque méthode obscure qui ne l'acceptait pas par nom...). Il faut simplement que les arguments soient passés dans l'ordre où ils figurent, et que pour les arguments optionnels omis lorsqu'on en utilise de situé après, leur position doit être marquée par la présence de virgules. Exemple : .....Find valeurcherchée, , xlValues On omet le 2e argument (point de départ de la recherche), mais sa position est indiquée, sans quoi VBA ne trouvera pas les suivants. Généralement, il est plus simple et plus court de passer par position, mais il peut s'avérer plus pratique de passer par nom dans certains cas. Exemple : Worksheets.Add ... Les deux premier arguments sont after et before, alternatifs, on ne peut utiliser que l'un ou l'autre. Dans ce cas mieux vaut mentionner, pas de risque d'ambiguïté et à la lecture on n'aura pas de doute. J'utilise les noms pour la méthode Range.Sort, car ils sont nombreux et à mon avis pas positionnés dans un ordre logique... Egalement, lorsqu'il y a un grand nombre d'arguments et qu'on utilise ceux qui sont en fin de liste. Exemple : Application.InputBox "Sélectionner une cellule", Type:= 8 Le premier est passé par position, le type indiquant qu'on attend un objet Range, situé en fin de liste, mieux vaut utiliser le nom pour éviter de passer du temps à ajuster le nombre de virgules intermédiaires nécessaires (on peut mixer passage par position et par nom, mais dès que l'on a passé un argument par nom, les suivants ne peuvent plus l'être que par nom (logique, VBA ne peut compter le rang qu'à partir du début). Il a raison sur le fond, s'il s'agit d'éviter que le programme plante sans savoir sur quelle erreur... Mais il ne faut pas être systématique, si l'on sait quelles erreurs peuvent survenir il peut être plus simple de les gérer... Et on peut aussi s'en servir positivement... Exemple : une proc. d'achivage utilisant un classeur d'archivage annuel. Tous les ans on va avoir le premier archivage sur lequel le classeur annuel est à créer. Dans la procédure on a une ligne qui ouvre le classeur, on met cette ligne sous gestion d'erreur. Une fois par an, erreur, la gestion de l'erreur crée le classeur annuel, et l'exécution se poursuit à la suite dans les mêmes conditions que si le classeur avait été ouvert...

paritec · Answer

Oui Mferrand je suis 100% d'accord avec toi, mais si on prend l'habitude de coder sans l'utiliser, cela oblige à gérer les erreurs possibles, et on l'utilise "que" et "uniquement" à bon escient bonne journée Papou...

MFerrand · Answer

J'ai jeté un oeil rapidement sur le cours de ton prof... dense et compact, particulièrement étendu... Intéressant donc, et il a un certain humour, ce qui ne gâche rien. J'ai mis de côté pour pouvoir y revenir.

Il est évident qu'en 5 jours, tu n'absorberas jamais l'ensemble... Mais c'est pas le but. Il faut un minimum pour pouvoir opérer et on le complète au fil des réalisations...

Il y a des chapitres sur lesquels il n'est jamais inutile de revenir, on en tire toujours quelque chose de plus à chaque foir : variables et procédures, tableaux... Et selon ce que tu fais tu te consacres à accumuler à tel ou tel moment ce qui sert pour la réalisation en cours.

Ton PDF joint : ces quelques lignes ne suffisent pas pour faire le tour de la question (comme je l'ai dit c'est compact...), il y a des explicitations du contenu de cette diapo dans d'autres : la dernière ligne par exemple, via des valeurs de retour réfère au renvoi de résultats par des procédures Function, via des paramètres réfère aux passages d'arguments à des procédures, éléments que j'ai vu au passage dans d'autres diapo (dans le peu que j'ai pris le temps de regarder).

Pour ce qui est de "grosses macros", suis ses conseils, éclate ça en morceaux plus petits ! On appelle ça programmation modulaire, et les résultats en sont meilleurs, et font gagner du temps...

Les variables de niveau module, qu'elles soient publiques ou normales (privées par défaut) sont pratiques pour y stocker des valeurs ou objets à rendre accessibles à toutes les procédures d'un module ou du projet dans son ensemble. Elles occupent cependant une place permanente en mémoire, et il est prudent de ne pas en abuser et de le réserver aux quelques besoins pour lesquels cette méthode simplifie et facilite vraiment la programmation.

Les variables de niveau procédure n'ont d'existence que le temps d'exécution de la procédure, la mémoire est donc vidée à la fin...

Les éléments utiles à une procédure appelée peuvent lui être passés en arguments par la procédure appelante, et dans beaucoup de cas recourir à une variable module n'apporte pas de gain par rapport à cette méthode.

Certains paramètres peuvent être rapidement reconstitués par calcul, ou lecture d'une propriété, sans avoir besoin de la passer ou de la stocker dans une variable... Et on peut également recourir à des procédures Function pour renvoyer certains paramètres modifiables...

Il faut rechercher le bon compromis parmi tous les moyens disponibles pour arriver à celui qui s'avèrera le plus économique (fiable et rapide).

Pour les modules... je me réfèrerai volontiers aux constats d'Ifrah [Histoire universelle des chiffres] qui note que jusqu'à 4 on n'a pas besoin de compter, on perçoit les différences quantitatives sur le même mode que les différences qualitatives, c'est au delà qu'on a besoin de réaliser une opération qui s'appelle compter et ce pourquoi on a inventé la numération (et les systèmes de numération)... Pour les modules, je trouve sage de ne pas les multiplier, et autant que possible de ne pas dépasser 4.

Au-delà, on perd pas mal de temps à chercher dans quel module on a bien pu fourrer... !

Je n'ai jamais rencontré de problème de saturation quantitative de contenu d'un module (le plus volumineux que j'ai pu faire approchait la centaine de pages imprimées en petits caractères, [je n'ai pas compté les lignes ni les procédures]).

A mon avis, on doit avoir un module principal dans lequel on met en principe tout. Et si on n'y met pas quelque chose, pour le positionner dans un autre module, ce doit être justifié par la nature de ce qu'on excentre. Par exemple, un module pour stocker des variables (pas publiques ! ainsi non accessibles directement d'autres modules), initialisées à l'ouverture et utilisées dans toute l'application, affectées et appelées par des procédures Property... ; ou bien un module dans lequel on place des déclarations de fonctions API, avec les procédures qui les utilisent...

Si on a une application avec des grandes parties fonctionnelles distinctes, il peut être judicieux de les séparer... Si un élément fonctionne comme une sous-application, utilisée par l'application principale, mais qui peut jouer le même rôle pour une autre application, et donc être exportée avec profit pour être également utilisée ailleurs, là on a tout intérêt à avoir un module distinct exportable (et importable)...

Mais de façon générale, on n'a aucun intérêt à émietter ce qu'on programme dans une multitude de modules.

Cordialement.