bonjour,

Comment faire lorsqu'on écrit des procédures (SUB) en VBA sous EXCEL destinées à un classeur, pour qu'elles soient dans un seul et même module et qu'il n'y ait pas plusieurs modules .?

Bonjour,

Tu les copies dans un même module, et tu supprimes les autres ensuite.

bonjour,

En fait ce n'est pas exactement cela que je voudrai savoir; mais comment empêcher la création de nouveaux modules .

Par défaut il existe toujours (je crois) un module appelé module1.

Si on écrit une nouvelle procédure à partir de l'éditeur VBA, elle se range dans un module2.

Comment faire pour que tout aille dans module1 ?

Non, pas de module préexistant par défaut, s'agissant de modules standard.

Quand tu veux créer une macro [taper le code, pas enregistrer une macro à partir d'une manipulation ], tu insères un nouveau module dans l'éditeur s'il n'y en a pas déjà ou si tu en veux un autre...

Par contre l'enregistrement insère un nouveau module. Si tu enregistres plusieurs macros lors d'une même session, elles vont dans le même module. Mais lors d'une nouvelle session, un nouveau module sera inséré. Je n'ai jamais vu de réglage de paramètres à cet égard (je n'en ai pas cherché...) Mais tu organises ensuite tes macros comme tu l'entends, et à toi de les regrouper dans un seul module...

merci.

Et autre question

Pourquoi si, au lieu de taper Sub on tape Private Sub , la procédure saisie de la sorte (précédée de Private) n'apparait pas dans la liste des macros ?

Parce que comme tu l'indiques, elle est alors privée, donc non accessible en dehors du module où elle se trouve...

Les questions de portée des procédures ou des variables paraissent un peu complexe au départ mais en procédant dans l'ordre on s'y retrouve :

- les objets VBA (modules, procédures, variables, ...) peuvent être publics ou privés ; on utilise les mots-clés Public ou Private dans les déclarations pour définir cette portée, mais il y en a une par défaut, qui s'applique lorsque l'un de ces deux mots-clés n'est pas utilisé d'une part, et d'autre part la portée s'applique différemment selon l'interaction provoquée entre ces différents objets (par ex. procédure privée dans un module public, ou procédure publique dans un module privé...)

- les modules standard sont publics par défaut (ce pourquoi on y accède sans avoir à indiquer de nom de module) ; pour rendre un module privé, il faut mettre la déclaration : Option Private Module en tête du module ;

- les procédures sont publiques par défaut : un procédure Sub ou Function fonctionnera dans un module standard comme si tu l'avais déclarée Public Sub ou Public Function; on peut l'appeler simplement par son nom de n'importe où (si tu as rendu le module privé, elle demeure accessible mais seulement à partir du projet concerné [le classeur] et en indiquant le nom du module, ex. : Module1.MaProc) ;

- une procédure privée dans un module standard n'est vue que dans le module où elle se trouve : il te faut alors passer par une autre procédure du même module pour pouvoir y accéder ; exemple : Private Sub MaProcPrivée dans un module, Sub MaProcPublique dans le même module, cette dernière lance MaProcPrivée, donc si tu appelles de l'extérieur du module MaProcPublique, celle-ci lancera MaProcPrivée, mais tu ne peux le faire directement ;

- les autres modules sont privés par défaut (modules de feuilles, module ThisWorkbook, modules des Userforms que tu crées, [et modules de classe destinés à la création d'objets personnalisés, que je laisserai de côté ici]) : ils sont notamment destinés à accueillir des procédures d'évènements qui, elles par définition, sont privées et toujours assorties du mot-clé Private ; si tu insères une procédure ordinaire dans un de ces modules, par exemple celui de Feuil1 : Sub MaProc, elle sera publique, mais dans un module privé ; tu ne peux l'appeler par MaProc, mais tu peux dans le projet par Feuil1.MaProc ;

- à l'inverse, les variables sont privées par défaut : dans Module1, tu déclares au niveau module Dim MaVariable, tu pourras utiliser MaVariable dans une procédure de Module1 mais pas dans un autre module ; tu déclares Public MaVariable, tu pourras l'utiliser dans une procédure d'un autre module ; dans le cas d'un module privé, par exemple Userform1, tu déclares Dim MaVar au niveau module, tu peux utiliser MaVar dans toutes les procédure du module, mais pas à partir d'un autre module ; tu déclares Public MaVar au niveau module dans Userform1, dans une procédure de Module1, tu lances l'exécution de Userform1 (par la méthode Show), ta procédure reprend la main lorsque Userform1 est masqué, tu peux alors récupérer dans la procédure de Module1 la valeur de MaVar en l'appelant par Userform1.MaVar...

Tu vois que pour apprécier la portée et la visibilité, il te faut prendre en compte une combinaison d'éléments : la portée par défaut ou modifiée par déclaration de l'élément considéré, la portée par défaut (ou éventuellement modifiée) de l'élément qui le contient.

merci.

De rien ! Petit complément sur la spécificité de ta question.

Les procédure qui apparaissent dans la liste des macros sont toutes des procédures publiques et si elles sont dans un module privé, elles apparaissent sous la forme : NomModule.NomProcédure.

Si la macro doit être lancée en lui fournissant des arguments, elle n'apparaîtra pas non plus dans la liste.

Ex.: Sub MaProc(MaVar As Integer) est publique mais n'apparaît pas dans la liste.

Il faut la lancer à partir d'une autre procédure qui lui fournit les arguments qu'elle attend pour s'exécuter.

En principe, tu utilises la liste des macros, soit pour lancer directement, soit pour l'affecter à un bouton ou autre contrôle. Le plus souvent ces macros n'exigent pas d'argument, donc pas de difficulté pour les diverses manipulations.

Dans ces cas, si la macro a besoin d'éléments qui ne lui sont pas fournis en arguments pour réaliser ce qu'elle a à faire, c'est elle-même qui va les définir ou les extraire au cours de l'exécution.

Note que tu peux réaliser l'affectation d'une macro avec argument à un bouton, mais pas manuellement, il te faut alors créer une autre macro (temporaire le cas échéant) pour réaliser l'affectation. Ce n'est pas toujours très pratique, mais envisageable dans certains cas (bouton auquel tu veux changer la macro affectée après chaque exécution...)

Par contre dans le cas d'une macro qui calcule les éléments dont elle a besoin, par exemple une macro affectée simultanément à plusieurs boutons et qui agira différemment selon le bouton qui la lance, si elle était lancée directement à partir de la liste au lieu d'un bouton cela pourrait entrainer une erreur. Dans ce cas tu as intérêt qu'elle ne soit pas visible dans la liste !

Petite astuce pour y parvenir. Tu l'affectes d'abord normalement. Ensuite tu y ajoutes un argument optionnel (mot-clé Optional). Cela la fait disparaître de la liste, mais n'empêche pas son lancement sans argument puisque l'argument est optionnel.

Salut Ferrand

Je viens de lire tes explications du 14 juillet sur les macros avec attention.

j'ai une question

Il y a bien longtemps, je m'énervais avec les msgbox à 1 seul bouton car la souris ne se positionne

pas aoutomatiquement sur le bouton OK

Le forum excelabo d'alors m'avais donné la solution.

Private Declare Function SetCursorPos Lib "user32" _
(ByVal X As Long, ByVal Y As Long) As Long

et dans la macro ou est le msgbox

X = 400: Y = 345: SetCursorPos X, Y
et j'ai ma souris sur le bouton Mais comme tu le dis,je dois appeller cette fonction par une autre macro

Quesque je risque à supprimer le mot "Private" voire à inclure directement cette fonction dans la macro

Le message est fermé mais j'essaie quand même.

Bonjour,

La fonction dont tu fais état appartient à Windows. Elle fait partie du système d'exploitation et elle se trouve dans user32.dll, c'est une fonction API utilisable par n'importe qu'elle application tournant sous Windows, donc éventuellement par Excel (et VBA).

L'instruction que tu mets en tête de ton module n'est pas la fonction, c'est une instruction de déclaration : tu indiques à VBA que tu vas utiliser cette fonction externe en lui indiquant où elle se trouve et quels arguments doivent lui être fournis pour qu'elle produise le résultat attendu. Ce type d'instruction étant privé par définition, enlever le mot clé n'y changerait rien, sauf peut-être perturber le programme dans certains cas (je n'ai jamais essayé, je ne peux donc dire si ôter Private l'empêcherait de fonctionner où pourrait produire d'autres effets ; en tout cas cela ne la rendra pas "publique").

Normalement, quand tu fais une déclaration de ce type, tu crées dans le même module une procédure (qui elle sera publique [par défaut, donc inutile de le mentionner], sauf si tu la déclares privée, mais ce serait contradictoire avec l'objectif !) pour utiliser cette fonction API (tu peux même en créer plusieurs à des fins différentes).

Pour bien faire, avant de positionner le curseur, il aurait fallu calculer l'emplacement de la fenêtre et celui du bouton... (autres fonctions API peut-être ?). Là il semble qu'on positionne un peu au hasard, sachant que par défaut la fenêtre de message va s'ouvrir au centre de l'écran. On va donc se rapprocher du bouton sans être sûr d'arriver dessus.

Bonjour

les coordonnées données sont en effet valables pour une fenetre normale, a la taille de l'écran.

Mais je travaille à 95% dans cette configuration alors c'est pas grave.

Tu me dis que tu ne sais pas trop ce que donnerait une déclaration PUBLIC alors je ne touche rien !

Ca marche alors c'est bien comme ça.

Merci pour ces précisions

Edit : Les coordonnées ont été trouvées avec le petit logiciel Pixie

JMM