Re le fil,
Salut Hervé,
Pour moi, la clé du problème se situe non seulement au niveau de la
durée de vie de la variable mais aussi,
et surtout, au niveau de la
portée que l'on veut donner à la dite variable.
Une variable
Public ou
Private déclarée
au niveau Module trouve son utilité uniquement si elle doit être 'partagée' entre plusieurs procédures. Par exemple, si je décidais de chronométrer la durée d'ouverture d'un classeur, je déclarerais une variable
vTemps au niveau module de l'objet ThisWorkbook, je lui affecterais l'heure courante dans l'évènement Open() et je réutiliserais sa valeur dans l'évènement BeforeClose() du même objet pour calculer la durée de cette session.
Dans le cas de la macro que je présente plus haut, la situation est différente : la contrainte se situe uniquement au niveau de la durée de vie de la variable. Cette dernière n'est utilisée que dans une seule et unique procédure. La portée étant donc restreinte, une simple variable déclarée
Static à l'intérieur même de cette procédure, suffit à répondre à la seule contrainte de durée de vie.
J'ai effectivement l'habitude (bonne ou mauvaise) de privilégier l'utilisation des variables Static quand j'en ai la possibilité. Je les trouve beaucoup plus faciles à gérer. Pour moi, plus la portée de la variable est restreinte, et plus il devient facile d'en maîtriser le contenu. On réduit d'autant les risques de changement de valeur inatendu à un autre endroit dans le code...
On peut ainsi déclarer des variables
Static avec le même nom dans plusieurs procédures différentes. Chacune de ses variables reste donc indépendante et conserve sa propre valeur dans sa propre procédure. Moi, je trouve ça pratique...
Amicalement,