conception pour macro gérant d'autres macros et pour macros gérées

Bonjour à tous,

J'ai des grandes questions de méthodologie.

J'aimerais créer une macro qui gère d'autres macros.

Les macros gérées demandent de faire entre autres des sélections (par exemple les classeurs sur lesquels il faut faire une action).

Comment dois-je concevoir le projet pour faire toutes les sélections une unique fois au début du programme?

Actuellement mes macros sont conçues de cette façon :
Dans chaque module, j'ai une "grosse macro" (en public) qui est autonome grâce à ses "sous-macros" (en private) => module autonome pour l'import et donc réutilisation dans d'autres projets.

Dois-je créer 2 versions d'une même macro : une autonome et une avec paramètres, avec les "sous-macro" dans le module quelque soit le cas?

J'ai pas tout compris.

Ton programme, il appelle tes macros publiques?

Bonjour decondelite!

Oui, j'aimerais appeler mes macros publiques.
(ce n'est pas très simple à expliquer comme problème car je ne sais pas du tout comment m'y prendre)

J'ai un programme principal à concevoir.
Celui-ci ne fera qu'appeler d'autres macros (je parcours les classeurs contenant les macros et sélectionne mes macros publiques)

Chaque macro publique est dans un module différent car réside avec ses "sous-macros" qui sont privées (pour éviter les problèmes et pour pouvoir réutiliser mes macros dans d'autres classeurs. Je ne sais pas s'il faut s'y prendre autrement, avec des .xla par exemple)
Chaque macro publique me demande de faire des sélections.

J'aimerai faire toutes mes sélections au démarrage et laisser tourner le programme.

Je n'ai pas de "vraie" méthodologie car non formé pour ça.
Dois-je avoir 2 versions pour chaque macro : une classique sans paramètre à utiliser telle qu'elle et une avec paramètres pour être gérée par une autre macro?
Ou y a-t-il une façon de concevoir mes macros qui me permettrait de n'avoir qu'une seule version de chaque macro à appeler, utilisable dans les 2 cas?

J'ai besoin d'avoir une base aussi solide que possible pour monter des projets plus important par la suite.
Pourrais-tu me dire comment m'y prendre?

Ce que tu peux faire dans ta "macro qui gère les autres", c'est d'appeler tes sous-macros avant tout traitement.

Quoi que soit ton choix, garde bien en tête que tes sous-macros devront toujours fonctionner de la même façon, et que si tu veux créer un lien avec la macro principale, tu devras créer des variables publiques dans ton module de macro principale et gérer leur existence dans chacune de tes sous-macros.

Ceci-dit, si tu expliquais en quoi consistent concrètement chacune de tes macros, je pourrais peut-être te donner une réponse un peu plus précise et surtout plus sûre et adaptée. ;)

Merci pour ta réponse decondelite.

En fait, j'ai modifié mes macros publiques afin qu'elles acceptent des paramètres de façon optionnels (je ne connaissais pas :D).
De cette façon, je n'ai plus besoin de créer 2 versions de chaque macro.
J'avais déjà remonté le traitement de l'utilisateur au début des macros, donc avant traitement. C'est encore en cours car je récupère d'anciennes macros où j'étais moins doué qu'aujourd'hui => bcp de boulot encore pour les mettre à niveau mais pas de souci je saurais faire.

Par contre pour utiliser la macro de façon autonome : juste en insérant le module contenant mon pack de macro (la publique et les privées) donc sans passer de paramètre, je suis obligé de créer une autre macro qui l'appel. (A première vue, on ne peut pas lancer directement une macro avec paramètre.
Donc je me retrouve avec quelque chose comme ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

public sub Macro_autonome 'Macro pour lancement autonome call macroParametree end sub   public sub macroParametree(optional param as string) 'Macro pouvant être appelée par une autre (ne peut pas être lancée autrement que par une autre...) if param ="" then 'récup valeur de param end if   'Traitement     end sub

---

Qu'en penses-tu? Dois-je m'y prendre autrement pour que la macro puisse être lancée directement, sans être forcément lancée par une autre?


J'ai aussi réfléchi à la présence de variables publiques et je suis plutôt contre car je les trouve dangereuses (d'un programme à l'autre, je pense que l'on peut avoir des surprises non?)

Je pense que l'on doit pouvoir avoir l'équivalent de la praticité de ces variables publiques, en passant les variables locales en paramètre dans les "sous-macros"(pour l'instant privées et présentes dans chacun des modules où la macro public le nécessite)

D'ailleurs, par la suite, si tu pouvais aussi me dire comment je devrais m'y prendre car effectivement, c'est bien pratique d'avoir des modules autonomes pour n'avoir qu'à insérer le module pour que la macro public fonctionne mais dans un programme plus important, les mêmes "sous-macros" peuvent apparaître plusieurs fois dans l'ensemble des modules insérés. (je ne trouve pas ça très malin mais je ne sais pas comment je dois m'y prendre)
Dois-je avoir pour des projets : un module avec toutes les macros de soutien ("sous-macros" qui sont habituellements privées) et un second module avec les macros publics (les grosses). Et à côté des modules autonomes comme maintenant à insérer simplement?

Je cherche une méthodologie qui me permettrait de concevoir des macros faites pour certaines fonctions (sélectionner un classeur ou autres) que je puisse réutiliser dans des projets plus grands. (pour l'instant c'est rikiki mais j'apprends!)

PS : c'est vraiment sympa d'avoir passé déjà tout ce temps pour moi, merci!

J'avais justement hésité à te proposer le passage d'arguments optionnels pour la raison que tu évoque: il est effectivement impossible d'exécuter une macro à paramètres depuis le menu "Macros". En revanche tu peux les lancer depuis un bouton de commande, une commande de barre d'outil, etc... Depuis un autre classeur par contre je ne sais plus si c'est possible: si c'est ton cas, je pense que je vais devoir fouiller dans mes archives pour retrouver un vieux sujet où j'en parlais.

C'est pourquoi je t'avais proposé les variables publiques. Mais ta solution avec macro d'appel me semble très bien c'est un bon choix pour t'affranchir des variables publiques. ;)
Je ne qualifierais pas les variables publiques de "dangereuses", mais je dirais plutôt que leur emploi rend un programme "sale" et "mange-mémoire", surtout quand on commence à en avoir beaucoup. C'est pourquoi personnellement je ne les utilise pas lorsqu'il y a une alternative qui ne serait pas trop lourde à implémenter (appel de procédures à ralonge par exemple).

Pour ton problème des "macros multiples", malheureusement je ne connais pas de code VBA qui "auto-implémenterait" ladite macro lorsqu'elle est absente. Et etant donné que vu qu'on va essayer d'éviter les solutions pas très simples (je pourrais essayer d'en trouver une si je voulais), on va plutôt faire dans le domaine "trucs et astuces". Voici donc quelques possibilités:
-1: identifier tes procédures communes de façon unique dans chacun de tes modules, par exemple dans l'un ce sera "OuvrirFichier_Module1", dans un autre ce sera "OuvrirFichier_Module2". Ca sera certes ridicule d'avoir plusieurs fois la même chose, mais simple à réaliser
-2: une solution un peu plus intelligente serait que tu fasse ouvrir un classeur xla, contenant une banque de procédures, tu l'ouvre depuis tes macros, et ce à condition que son projet ne soit pas déjà ouvert (je vais approfondir dans cette direction si c'est cette solution que tu souhaites utiliser: je ne suis pas un spécialiste des macros complémentaires mais ça ne me posera pas de problème). Cela ne fera qu'une seule instance par fonction, masi en revanche un module pourrait charger des fonctions dont il ne se servira pas.
-3: un compromis entre les 2 solutions précédentes, suivant la féquence d'utilisation de chaque macro

Il y a une chose qui m'interpelle depuis un moment, mais je n'avais pas encore osé te poser la question: tu inclues tes modules "à la main", ou tu ouvres des classeurs les contenant? Qui est censé faire cette tâche? Car suivant l'utilisateur certaines méthodes de développement seraient à privilégier plus que d'autres selon le cas. ;)

Pour le module inséré tout seul dans un nouveau classeur :
Je ne sais pas lancer une macro depuis un bouton de commande, mais effectivement ça serait bien si ça marche (l’idée est que ce soit rapidement réalisable dans ce cas)
Et si ça ne te dérange pas, je suis preneur pour étudier le lancement depuis un autre classeur :D

Les classeurs .xla, je ne connais pas mais ça semble pratique, quel est ton avis ? (en tout cas ça m’intéresserait de comprendre !)
Mais est-ce que dans ce cas, je dois créer pour chaque projet une .xla où je mettrais toutes mes macros de soutien, utiles au projet ? (pour pouvoir mieux s’y retrouver)
Par contre, je n’ai pas compris pour le module pouvant charger des fonctions dont il peut ne pas se servir.

Pour le moment, pour chaque « projet », effectivement j’inclus mes modules « à la main ».

Sauf que là, je suis en train de faire un programme allant chercher des macros publiques de classeurs fermés pour les lancer.
Les macros lancées sont des macros publiques faisant chacune appel à des macros privées de leur module. Cela peut-il fonctionner sans ouvrir les classeurs?

Pour le moment, l’utilisateur c’est moi, ce qui me permet de tester différentes façons de procéder (cela dépend directement de la vitesse à laquelle je comprends les choses :lol:).
Je n’ai pas encore de préférence particulière pour programmer car je n'ai pas de "méthodologie suffisante".
Pour le moment, j’élargis petit à petit mon univers VBA ;)

ps : à oui, les macros que je récupère sont dans une collection de string.
La forme est : nomclasseur!nomModule.nomMacro
(je me suis fait un petit formulaire pour les mettre dans l'ordre que je veux :D)

Citation:

---

Envoyé par buzz73

Pour le module inséré tout seul dans un nouveau classeur :
Je ne sais pas lancer une macro depuis un bouton de commande, mais effectivement ça serait bien si ça marche (l’idée est que ce soit rapidement réalisable dans ce cas)
Et si ça ne te dérange pas, je suis preneur pour étudier le lancement depuis un autre classeur :D

---

J'ai envie de dire que ce n'est pas le sujet, mais:
-lancement de macro depuis un bouton de commande: tout dépend de quel type de bouton tu prends (celui de "formulaires", ou celui de "boite à outils contrôles"), mais dans les 2 cas ça reste très simple à mettre en oeuvre
-lancement depuis un autre classeur: ça dépend de où tu appelles ta macro (depuis le code VBA ou depuis un bouton de commande)
Tout dépend de ce que tu veux faire précisément.

Citation:

---

Envoyé par buzz73

Les classeurs .xla, je ne connais pas mais ça semble pratique, quel est ton avis ? (en tout cas ça m’intéresserait de comprendre !)
Mais est-ce que dans ce cas, je dois créer pour chaque projet une .xla où je mettrais toutes mes macros de soutien, utiles au projet ? (pour pouvoir mieux s’y retrouver)

---

Mon avis est que tout dépend de l'utilisateur final. Si c'est toi oublie tout de suite les xla, car tu peux mettre tes macros de soutien dans divers modules indépendants des autres, que tu inclus "à la main".
Si c'est quelqu'un qui ne touche pas à VBA et qu'il faut néanmoins pouvoir ajouter/supprimer des macros, là tu devras mettre la sauce à créer un xla par module, ou alors regarder du coté du modèle objet VBIDE si tu as la possibilité d'automatiser l'import de modules à partir de fichiers modules VBA (comme quand tu fais importer/exporter un module depuis ton éditeur). Perso je regarderais cette deuxième option en premier, car cela permettrait de me simplifier un peu les appels de procédures par la suite et automatiserait l'ajout de modules "à la main".
En tout cas, tu regroupe tes procédures de soutien par thème, et tu fais un xla (ou un fichier importable) par thème: c'est le même principe que les références de projet, en un peu "customisé" si je puis dire.

Citation:

---

Envoyé par buzz73

Par contre, je n’ai pas compris pour le module pouvant charger des fonctions dont il peut ne pas se servir.

---

Bon on va expliquer avec un exemple.
Tu as dans ton projet deux modules A et B, qui font appel à des procédures d'un troisième module C. Supposons que dans ton module C il y a Procédure1, Procédure2, Procédure3 et Procédure4, que A utilise Procédure1 et Procédure3 et que B utilise Procédure2 et Procédure3.
Tu as donc une seule Procédure3 de chargée, ce qui économise de la place en mémoire, mais en revanche tu as procédure4 qui ne te sert à rien. Cependant tu ne peux pas enlever Procédure4, car celle-ci est utilisée par un module D qui utilise aussi Procédure1 et Procédure2, bien que tu ne l'aies pas inclus dans ton projet.
Prenons un cas concret: lorsque tu utilise la référence à Excel (Range,Application.DisplayAlerts & co), est-ce que tu utilise tous les éléments de ta référence? Non: il y en a plein qui ne te servent à rien dans ton projet.
Eh bien là c'est pareil avec tes modules: tu fais un module de procédures de soutien, mais toutes ne seront pas forcément utilisées, car il n'y aura aucun module qui fera appel dans ton projet, alors qu'il en existe bien un quelque part qui s'en sert.

Bien évidemment, prends garde à ne pas mettre tout et n'importe quoi dans ce module de procédures de soutien: ne mets que ce qui a des chances d'être réutilisable.

Citation:

---

Envoyé par buzz73

Pour le moment, pour chaque « projet », effectivement j’inclus mes modules « à la main ».

Sauf que là, je suis en train de faire un programme allant chercher des macros publiques de classeurs fermés pour les lancer.
Les macros lancées sont des macros publiques faisant chacune appel à des macros privées de leur module. Cela peut-il fonctionner sans ouvrir les classeurs?

---

Il se peut que je dise une bêtise, mais il me semble que la réponse est "non". A confirmer, si jamais quelqu'un a le courage de lire le pavé ici présent... :roll:

Citation:

---

Envoyé par buzz73

Pour le moment, l’utilisateur c’est moi, ce qui me permet de tester différentes façons de procéder (cela dépend directement de la vitesse à laquelle je comprends les choses :lol:).
Je n’ai pas encore de préférence particulière pour programmer car je n'ai pas de "méthodologie suffisante".
Pour le moment, j’élargis petit à petit mon univers VBA ;)

ps : à oui, les macros que je récupère sont dans une collection de string.
La forme est : nomclasseur!nomModule.nomMacro
(je me suis fait un petit formulaire pour les mettre dans l'ordre que je veux :D)

---

C'est pas vraiment une histoire de méthodologie les goûts et couleurs, c'est avant tout une histoire de bagage de connaissances (théoriques et pratiques, précises ou floues) et d'esprit avec lequel on développe.


Pour résumer, voici l'ordre des options que je te propose, de la plus simple à la plus difficile:
-1: tout simplement renommer chacune de tes procédures qui a des semblables dans d'autrres modules, et donc là tu ne te pose même pas la question de module à procédures communes. C'est sale, répétitif, difficile à mettre à jour, mais c'est simple
-2: faire des modules de procédures communes que tu ajoutes "à la main"
-3: faire les mêmes modules, l'exporter, puis essayer d'automatiser son import. Je répète que je ne sais pas si c'est possible: tout dépend de la possibilité ou non d'ajouter des modules automatiquement au projet VBA.
-4: encore les mêmes modules, mais que tu mets dans un fichier xla qui sera ouvert automatiquement

Merci beaucoup!
ça m'a bien éclairé :king: