Discussion :

[buzz73]

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?

[decondelite]

J'ai pas tout compris.

Ton programme, il appelle tes macros publiques?

[buzz73]

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?

[decondelite]

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.

[buzz73]

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 ).
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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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!

[decondelite]

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.