Reprise du message précédent :
Normalement lors de la fin d'une procédure toutes ses variables locales non statiques sont effacées.
Mais en ce qui concerne une variable objet, mieux vaut libérer ainsi les ressources allouées au pointage de cet objet …
Pour le choix d'un module normal ou d'un module de classe du classeur ou d'une feuille,
je n'indiquerais pas de meilleur emplacement car c'est un choix personnel, une habitude, une facilité même …
C'est comme pour le café, certains le préfèrent fort, d'autres allongé, sucré ou pas …
Lorsqu'il s'agit d'exploiter un évènement du classeur ou d'une feuille, il n'y a pas le choix,
le code doit se situer dans le module de classe correspondant au classeur ou à la feuille !
Et si dans ce code une fonction ou procédure est appelée, par simplicité autant qu'elle se trouve dans le même module …
L'avantage d'un module normal serait la réutilisation d'un code générique dans d'autres classeurs, suffit de l'exporter
d'un classeur source pour le sauvegarder sur le disque dur et lors de la création d'un nouveau classeur,
importer ce module éviterait de réécrire des procédures similaires …
Lorsqu'un projet comporte des milliers de lignes, il est plus simple pour s'y retrouver
de séparer par thème les procédures dans plusieurs modules …
De mon côté, c'est souvent du sur-mesure. L'avantage de coder directement dans un module de classe d'un classeur ou
d'une feuille permet en cas d'omission de toute référence à un classeur ou à une feuille de faire de facto référence
à ce classeur ou à cette feuille, simplifiant et sécurisant ainsi le code, même si un évènement change le classeur ou la feuille active !
Par exemple l'instruction Range, sans être précédée par une référence à une feuille de calculs, dans un module normal,
fait donc référence à la feuille active, ce qui s'avère problématique lorsqu'une autre feuille devient active …
Tandis que cette même instruction dans le module d'une feuille de calculs fait de facto référence à cette feuille
quelle que soit la feuille active !
Autre point à prendre en compte : lors de la copie d'une feuille de calculs vers un nouveau classeur par exemple,
le module de classe de cette feuille y étant rattaché se retrouve aussi dans la destination, tout dépend du contexte donc …
Récemment sur un autre forum, un intervenant était fier de présenter une solution d'environ 200 lignes
dont le demandeur signalait sa difficulté à s'y retrouver dans ce code pour l'adapter à son besoin - simple - et parfois
un fonctionnement aléatoire dans son environnement multi-feuilles.
Un autre intervenant et moi-même avons chacun proposé une solution tenant en un maximum de 30 lignes de code
bien plus efficace, sûre et plus facile pour le demandeur à appréhender.
Mais le primo intervenant nous a fustigé (du domaine de la cour de récréation en élémentaire !),
qu'on avait rien compris à son code, que le sien était modulaire (pourtant une vraie usine à gaz !)
et qu'il lui était ainsi plus facile pour l'utiliser dans divers classeurs …
J'ai l'impression qu'il était resté au moins vingt ans en arrière même s'il semble plus jeune de vingt ans !
Tout dépend donc de l'expérience de chacun et de la souplesse d'esprit, c'est comme les goûts, les couleurs …
Pour éviter souci et perte de temps, ne pas oublier la hiérarchie objet d'Excel :
Application (Excel) / Workbook / Worksheet / Range / méthode ou propriété …
Le Générateur de macros est un outil pratique pour voir quels objets, méthodes et propriétés sont utilisés lors de manipulation.
Mais ensuite il faut nettoyer le code afin qu'il devienne plus efficient
car travailler directement sur les objets est bien plus efficace et sûr, voir l'exemple en lien dans ce post …
FORUM HardWare.fr
