Pierre Fauconnier

Salut.

Je vois souvent des codes événementiels qui font "plein de choses"... Pas sûr que ce soit une bonne pratique!

Dans ce billet, j'explique déjà pourquoi il ne faut jamais appeler du code événementiel, chose que je vois trop fréquemment sur le forum et qui est pour moi une mauvaise pratique. Un code événementiel ne peut être "appelé" que par l'événement considéré, sinon ce n'est plus du code événementiel. Certains ont déjà du mal à ce stade, ...

Salut.

Dans les trois premiers billets, je vous exposais :

1. Les fonctions génériques pour l'accès aux données via ADODB ;
2. Les fonctions spécifiques pour la gestion d'une table via ADODB ;
3. Les interactions entre un userform VBA et Access.

Dans le deuxième billet, j'écrivais ceci:

Avec certains SGBD (système de gestion de base de données), il est possible de faire abstraction de la syntaxe SQL grâce aux procédures stockées, permettant au programmeur

...

Dans un précédent billet, j'expose la bonne façon de manipuler un userform en VBA. Aujourd'hui, une discussion mémorable sur le forum Excel VBA me permet à nouveau d'insister sur les mécanismes à mettre en place, car manifestement, les userforms sont souvent mal programmés et les mécanismes sous-tendant une utilisation professionnelle de ces outils sont largement méconnus et/ou incompris.

La discussion complète sur le forum est très intéressante car j'y détaille les mécanismes suite ...

Au risque de me répéter, je le rappelle encore et encore: Pas d'EXIT SUB dans vos codes. Ce n'est pas compliqué de bien coder, tout de même. Et il existe très souvent, même toujours, une alternative à une sortie prématurée de procédure ou de fonction.

Il ne faut qu'une seule sortie de procédure ou de fonction. Pourquoi? Parce qu'avoir deux sorties de procédure, voire plus parfois, c'est risquer de sortir sans "remettre les choses à leur place"! Apparemment, difficile à comprendre, ...