Gestion d'erreur

gesterr.dll (le programme en VB6 natif) ~  gesterr.zip (les sources du programme)

Si VB 6.0 n'est pas installé sur votre ordinateur, vous aurez peut-être besoin d'installer les Runtimes VB : DLL VB 6.0
Les deux DLL suivantes sont, en général, également nécessaires : VB6FR.DLL ~  MSCOMCTL.OCX
(pour NT/2000, à copier dans WINNT\SYSTEM32 - pour 95/98/XP, à copier dans WINDOWS\SYSTEM)

Le programme est constitué d'une feuille et d'un module Add-In. La feuille a cet aspect là : 4 boutons : 1 pour lancer la installer la gestion d'erreur, 1 pour l'enlever, 1 pour rafraîchir la liste, le dernier pour fermer la fenêtre. 1 contrôle TreeView (avec cases à cocher), pour sélectionner les procédures qui recevront la gestion d'erreur. Cocher un module sélectionne automatiquement toutes les procédures à l'intérieur (et inversement).

On s'attaque ici à l'élaboration d'un complément VB. Un complément est un programme qui est intégré à VB pour lui apporter des fonctions qu'il ne possède pas en standard. Le complément que je vous propose permet de ne plus se soucier de la gestion d'erreur lors de l'élaboration de vos applications.

Ce complément modifie votre code de manière à insérer une gestion d'erreur dans chacune des procédures que vous aurez choisi, il numérote chacune des lignes pour un retour d'information sur l'erreur plus important (utilisation de la fonction Erl de VB). Vous pouvez mettre et enlever à volonté (sans que cela ne pertube votre code) la gestion d'erreur. En fait, pour une utilisation sans risque, il faut mettre en place le code d'erreur avant chaque compilation, puis l'enlever lorsque l'on désire retoucher à un module, ou une fonction... J'utilise de manière professionelle maintenant ce complément depuis quelques mois, et j'obtient de bons résultats!

Le module Add-In contient les procédures classiques de mise en place d'un complément, je ne m'attarderai pas dessus donc. Le code est mis en place automatiquement. A noter peut-être que j'ai apporté quelques corrections, parce que il semble y avoir un bug dans la procédure de mise en place de l'icône du complément...
La feuille représente l'interface qui apparaît lors de l'utilisation sous VB. Elle montre la liste des procédures, fonctions, méthodes du projet courant. Le code est là assez commenté. Je ferais donc juste quelques remarques d'ensemble.

J'utilise une numérotation prédéfinie. Pour la première partie de la gestion d'erreur, une numérotation inférieure à 10, pour la seconde partie, une numérotation à partir de 500. J'estime que c'est suffisant, j'ai du mal à concevoir en VB une fonction de plus de 500 lignes!! Enfin, de toute manière, libre à vous de modifier le code pour qu'il corresponde à vos besoins.
La partie déclaration d'un module (ou d'une feuille) ne peut pas être numéroté, de même que la première de déclaration d'une fonction. Enfin, un cas spécial, le premier case d'un SELECT CASE ne peut pas être numéroté également.

Pour une certaine lisibilité dans le code, la numérotation est suivi d'un nombre d'espace fixe.
Lorsqu'on enlève le code de gestion d'erreur, on se base donc par rapport aux numéros de lignes. Il y a juste le cas spécial des lignes qui possèdaient déjà un libellé. Une ligne peut avoir un numéro et un libellé, mais il n'y aura qu'un espace entre les deux, il faut donc y faire attention.
J'utilise dans ce programme la fonction Erl qui renvoie la ligne à laquelle se produit une erreur. Bien entendu, cela ne fonctionne que lorsque la ligne est effectivement numérotée par l'utilisateur. D'où l'utilité d'un complément... je vous raconte pas s'il fallait en plus du code se taper les numéros de ligne à la main...

Mise à jour du 8 septembre 2000 (merci à PurL pour son retour d'erreur...):
* Le treeview sert maintenant pour l'affichage (c'est plus joli, non?). La représentation des différents éléments d'un projet VB est respectée (on retrouve les mêmes icônes que dans l'explorateur de projet). Seules les procédures "Public" et "Private" sont différenciées.
* Les entêtes de déclarations de fonctions sur plusieurs lignes sont (maintenant) correctement gérées.
* Les déclarations de fonctions API ne sont plus prises en compte, l'ajout de la gestion d'erreur commence donc bien à partir de la première déclaration réelle du code.
* Les commentaires en fin de procédure ne posent plus de problème. Lors de la version précédente, cela pouvait entraîner un décalage dans la numérotation et mettre alors la fin de la gestion d'erreur au mauvais endroit.

Mise à jour du 5 avril 2003 (merci encore à PurL pour son retour d'erreur...):
* Les lignes qui commencent par # (compilation conditionelle) ne sont plus prises en compte par la numérotation.
* Passage de la gestion d'erreur de la ligne 500 à la ligne 900. C'était un peu juste pour certaines grandes procédures.

Enfin, comme d'habitude, quelques idées d'améliorations. Pour une plus grande fléxibilité, on peut imaginer que le code d'erreur à ajouter soit configurable. Comme j'utilise régulièrement ce complément au bureau, il évoluera peut-être dans le temps... Sinon, faites moi part de vos suggestions d'évolutions.

frmAddIn.frm ( Afficher le code)