Quelle est la différence entre un code attaché à une feuille et à un module ?

"- Modules de feuille : l'objet parent est la feuille de calcul
- Module 'ThisWorkbook' : l'objet parent est le classeur
- Module de classe : l'objet parent est l'objet instancié à partir de la
classe
- Module standard : pas d'objet parent

L'objet parent est l'objet auquel se réfère le module. On peut accéder à
cet objet par le mot-clé "Me" (bien que ce ne soit pas indispensable).
Par exemple :

Me.Name dans le module "Feuil1" : renvoie le nom de la feuille
Me.Name dans le module "ThisWorkbook" : renvoie le nom du classeur
Me.Name dans le module "Class1" : renvoie le contenu de la variable ou
propriété "Name" de l'objet telle qu'elle est définie dans le module de
classe
Me.Name dans un module standard : génère une erreur d'exécution.

Les modules de feuille et 'ThisWorkbook' sont des types particuliers et
prédéfinis de modules de classe. Ils sont destinés à contenir le code
relatif à l'objet parent et aux objets qu'il contient (procédures
événementielles de la feuille de calcul ou du classeur).

Ceci concerne essentiellement :

1) Les procédures événementielles

Par exemple :

- Si l'on veut intercepter toutes les saisies de l'utilisateur dans la
feuille Feuil1, on utilise en principe l'évènement Worksheet_Change de
son module de code.

- Si l'on veut intercepter les saisies dans n'importe quelle feuille du
classeur, on utilise l'évènement Workbook_SheetChange du module
'ThisWorkbook'.

- Si l'on veut intercepter les saisies dans n'importe quelle feuille de
n'importe quel classeur, on utilise l'événement App_SheetChange d'une
variable Application définie dans un module de classe.

Comme l'application est conteneur du classeur, qui est lui-même
conteneur de la feuille, on peut aussi intercepter par exemple les
saisies dans une feuille particulière à partir de Workbook_SheetChange
ou même d'une procédure App_SheetChange, mais c'est moins direct et pas
vraiment approprié.

2) Les objets :

Tout le code d'un contrôle (bouton, etc) posé dans une feuille de calcul
doit impérativement (procédures événementielles attachées au contrôle)
ou devrait être (autres procédures) placé dans le module de cette même
feuille.

Un piège classique : quand on utilise la propriété Range() seule sans la
faire précéder de Worksheets("..."):

- Dans les modules standard, la feuille contenant le Range sera
implicitement la feuille active (Range("A1") renvoie donc
ActiveSheet.Range("A1")).
- Dans les modules de feuille, il ne s'agit *pas* de la feuille active,
mais de la feuille parent du module (Range("A1") renvoie
Me.Range("A1")). Si l'on veut se référer à la feuille active, il est
donc nécessaire dans les modules de feuille de l'identifier
explicitement: ActiveSheet.Range("A1").

3) Les fonctions personnalisées :

Il est impossible d'appeler dans une formule sous Excel une fonction
perso définie dans un module de feuille ou le module 'ThisWorkbook'. Il
faut les définir uniquement dans des modules standard.

4) La persistance des modules :

Les modules de feuille étant attachées à des feuilles de calcul, si l'on
déplace ou supprime celles-ci, les modules seront déplacés ou supprimés
en même temps. Les modules standard et de classe ne peuvent pas être
affectés par les manipulations de l'utilisateur sous Excel. Le module
'ThisWorkbook' est indestructible.

Conclusion : en principe, tant qu'on ne manipule pas des procédures événementielles ou des contrôles posés sur des feuilles, il vaut beaucoup mieux placer son code dans des modules standard plutôt que dans des modules de feuille ou 'ThisWorkbook'.

Les modules de feuille et 'ThisWorkbook' sont essentiellement employés pour définir des procédures événementielles attachées respectivement aux feuilles de calcul (ou aux objets qu'elles contiennent) ou au classeur dans son ensemble. Les modules de classes sont essentiellement utiles pour gérer des événements de niveau application.

OUF !!! J'espère que j'ai rien oublié...

Et en complément parce qu'il est intarissable sur le sujet, la réponse humoristique de LL, qui a au moins le mérite d'être claire !

Au fait, sa conclusion c'est que ça ne sert pas à grand chose... voire à rien du tout !

Mais l'exemple ci-dessous montre que ... si quand même ça peut servir :-)
Astuce illustrée par ce classeur
dm-moduleclasse