Liste des variables pour gestion d'erreur Fermé

Question

Bonjour à tous,

Je développe sous ACCESS 2003/2007/2010.

J'utilise une gestion d'erreur fonctionnant ainsi :
- En cas d'erreur, je lance, sans paramètre, une fonction d'affichage de l'erreur
- Cette fonction retrouve automatiquement le nom de la sub/fonction ayant déclenché l'erreur, ainsi que le nom du module contenant la fonction ayant déclenché l'erreur.

Afin d'améliorer l'efficacité de débugage, je souhaiterais que cette fonction puisse inclure dans mon rapport d'erreur le nom et la valeur de chaque variable déclarée dans la sub/fonction ayant déclenché l'erreur.

Bien entendu, cela se passerait sans argument transmis à la fonction d'affichage de l'erreur.

Pour résumer : ma fonction de création du rapport d'erreur devrait :
- Reconnaitre la fonction ayant déclanché l'erreur (C'est déjà opérationnel)
- Reconnaitre le module contenant la fonction ayant déclanché l'erreur (C'est opérationnel aussi)
- Lister les variables déclarées dans la fonction et indiquer leur valeur (Là, ça coince...)

L'idéal serait une collection de variables... qui existe bel et bien dans Access (Fenêtre Variables Locales), mais je ne sais pas y accéder par VBA

Reconnaissance éternelle et profond respect à celui/celle qui me donne un bon tuyau là-dessus.

Merci et bonne journée.

Gégé

Plus je connais les hommes, plus j'aime ma femme !

Patrice33740 · Answer

Pour le débugage, n'est-il pas plus simple de mettre un simple Stop dans le gestionnaire d'erreur ?

GégéLAMBERT · Answer

Merci pour la piste...

Mais l'application est déployée chez 4 utilisateurs, et il faut que je récupère les infos d'erreur sans pour autant planter les utilisateurs...

Gégé

GégéLAMBERT · Answer

UP....
Je vois bien que la question est simple et la réponse complexe.
Mais je sais aussi que CCM compte des membres tellement balèzes que l'un d'entre eux à sûrement ma réponse !!!
(Je flatte, je flatte...)

Alors, les Dieux VBA de CCM, pas inspirés ? ;-)

Gégé

lermite222 · Answer

Bonjour,
De quel façon le "rapport d'erreurs" te parvient-il ?
A+

GégéLAMBERT · Answer

Bonjour Lermitte222,

J'utilise le principe de cette gestion d'erreur dans plusieurs applications. Suivant les cas, ça peut être :
- Un simple message donné à l'utilisateur ,
- L'enregistrement dans un fichier log (local ou sur FTP)
- L'envoi d'un mail au support.

Mon pb, c'est de pouvoir l'enrichir avec les noms et valeurs des variables de la fonction/sub ayant généré l'erreur, au moment où l'erreur est générée.

La lecture, par VBA, de la fenêtre des variables locales pourrait être la solution, mais je ne sais pas y accéder.

Gégé

GégéLAMBERT · Answer

Je monologue...

Petite lueur d'espoir : à partir du Handle de la fenêtre "Variables locales", et a l'aide des API EnumChildWindows, GetWindowText et GetClassName, j'accède aux contrôles de la fenêtre "Variables locales" et je peux lire leur contenu...

Mais...
Je crois que j'avance, et puis j'avance pas, parce que :
Tous les contrôles ne sont pas énumérés par EnumChildWindows : j'ai la fenêtre, les ScrollBars, le Bouton, mais pas le contenu du tableau des variables.

Donc, nouvel appel au secours : est-ce que quelqu'un a une méthode pour accéder à ces contrôles et à leur contenu ? Un équivalent de EnumChildWindows, mais qui va jusqu'au bout de la démarche ?

Merci d'avance.

Gégé

 
Plus je connais les hommes, plus j'aime ma femme !

lermite222 · Answer

Re,
est-ce que quelqu'un a une méthode pour accéder à ces contrôles et à leur contenu ? Beh... non, j'ai pas de piste sur ce sujet.
Serait pas plus simple dans la détection d'erreur de créer un fichier Log avec tout ce que tu veux ?
A+

GégéLAMBERT · Answer

Bonjour lermite et merci de te pencher sur mon pb.

Le pb, d'ailleurs, n'est pas de créer un fichier log... le pb, c'est l'autre partie de ta question : "avec tout ce que tu veux" !

Heureusement, le fait de pouvoir récupérer les variables et leurs valeurs dans la fonction ayant déclenché l'erreur n'est pas bloquant. C'est juste une piste que je suis depuis quelques temps, et que j'aimerais voir aboutir.

J'ai l'impression de pas être loin. Il faut juste que je trouve la solution pour accéder, via leur handle, aux contrôles "complexes" de la fenêtre des variables locales, puisque, pour l'instant, je me contente du titre de la fenêtre, des scrollbars, le bouton... Tout ce dont je n'ai aucune utilité, en fait !

A moins que, tout droit sorti du chapeau, mon sauveur arrive sur son fier destrier blanc, et me donne la fonction qui permet d'énumérer, pour une procédure donnée, toutes ses variables et la valeur de chacune...

Je perds pas espoir...

Gégé

Patrice33740 · Answer

Bonjour Gégé,

Le texte de la fenêtre variables locales ne semblant pas facilement accessible, je te propose une autre piste (pas forcement très simple!).

Si tu utilises l'option Explicit, toutes les variables sont déclarées. 
Tu connais le module et la procédure, une analyse du code, plus particulièrement des lignes de déclaration, doit permettre d'établir la liste des variables déclarées dans chaque portée et donc d'enregistrer leur valeur.
Mais, vu la multitude de propriétés des objets il faudra que te définisse un cahier des charges limitatif !  

D'autre part, plutôt qu'enregistrer toutes les variables, il me semble suffisant d'enregistrer uniquement celles qui sont susceptibles de provoquer l'erreur : lorsque les lignes de code sont numérotées, la fonction ERL() renvoi le numéro de la ligne de code qui provoque l'erreur. Il suffit d'enregistrer uniquement les variables de cette ligne.

voir ce lien https://silkyroad.developpez.com/VBA/VisualBasicEditor/#LII-D

GégéLAMBERT · Answer

Bonjour Patrice, et merci pour la piste.

J'ai, effectivement, fait une procédure d'analyse de ma fonction qui me renvoie le nom des variables (et... oui, j'utilise systématiquement l'option explicit).

C'est une des premières pistes que j'ai suivie. Malheureusement, je n'accède qu'aux noms de variables, et pas à leur valeur. C'est agaçant !

La numérotation des lignes permet d'avoir plus de précision sur le déclenchement d'erreur, mais je trouve le système, non natif dans VBA, assez lourd à vivre au quotidien sur un code en cours d'élaboration.

C'est vrai que le MZ-Tools simplifie la chose... Mais, si ERL m'indique la ligne, je n'ai toujours pas accès aux valeurs de mes variables. 

Je tourne en rond. Je m'approche, mais j'arrive pas à ouvrir la dernière porte !

Heureusement, c'est pas bloquant pour mes développements en cours. On va dire que c'est de la recherche fondamentale... ça fait sérieux :-)

En tout cas, merci de te pencher sur mon problème, et n'hésite pas à me suggérer d'autres pistes. Je suis preneur !

Gégé

GégéLAMBERT · Answer

Up...

Ben dîtes donc, ça n'inspire pas les foules, ma "petite" question...

Si j'avance, je viendrais donner la solution...

Gégé

Patrice33740 · Answer

Bonjour,

J'ai la chance d'être actuellement en vacances, je ne renterais donc pas dans le détail, mais je pense qu'il est possible de créer une procédure ad hoc à laquelle on transmet le nom de la variable et qui retourne sa valeur. 

C'est un peu tordu mais l'idée c'est de modifier cette procédure par macro pour qu'elle donne le bon résultat.
 
Bon courage

GégéLAMBERT · Answer

@Patrice
C'est maintenant moi qui suis de retour de vacances...
Alors, toujours partant pour cogiter sur mon pb ?

Gégé

GégéLAMBERT · Answer

Bonjour,

Je viens d'explorer  une autre piste, initiée par Patrice33740, mais je n'aboutit toujours pas.

J'ai créé une sub Liste_VARIABLES que j'appelle en début de traitement d'erreur. Cette sub va: 
- Lire les lignes de la fonction ayant déclenché l'erreur,
- Détecter mes déclarations de variables,
- Créer des lignes de code permettant de concaténer le nom et la valeur de chaque variable,
- Ecrire ces lignes de code dans le traitement d'erreur, juste après l'appel de ma sub Liste_VARIABLES.

C'est beau, et ça fonctionne...
Mais, car il y a toujours un Mais !

Les lignes de code que ma sub vient d'écrire ne sont pas exécutées, comme si la fonction ayant déclenché l'erreur avait chargé en mémoire, dès le début de son exécution, tout son contenu, et que le contenu modifié n'était pas pris en compte...

Donc, question : y a-t-il un moyen de rafraichir tout ça afin que les lignes que je viens d'insérer soient exécutées ?

Je tourne en rond !!!

Merci à ceux qui se pencheront sur le sujet.

Gégé

Patrice33740 · Answer

Boniour Gégé,

Désolé de te laisser chercher seul mais ces temps-ci je suis très occupé et je passe peu temps sur le Forum.

Si tu écris les nouvelles lignes de code dans une autre Sub que tu appelles après l'appel de ta sub Liste_VARIABLES ???

Ou autrement, peut-être qu'un DoEvents avant le code ...

GégéLAMBERT · Answer

Bonjour,

Un petit UP, pour voir si quelqu'un possède une solution, une piste, un indice... je suis preneur.

Donc, j'ai continué mes recherches, mais toujours sans obtenir de résultat.

Le problème de ma fonction qui est compilée en début d'exécution et qui, de fait, ne prend pas en compte les modifications que j'y apporte pendant son exécution me bloque toujours.

J'ai essayé un DoCmd.RunCommand acCmdCompileLoadedModules... sans effet.
J'ai essayé aussi acCmdCompileAllModules et acCmdCompileAndSaveAllModules, tous les deux provoquent des plantages d'appli systématiques ou aléatoires...

J'ai fouillé dans les tables système, au cas où l'appli y stockerait mes variables et leurs valeurs... rien trouvé, ça aurait été trop simple.

Désespéré, j'ai cherché du côté de la base de registre... C'est pas là non plus qu'ACCESS stocke ce qui m'intéresse. Dommage.

Et pourtant, c'est sûr : ACCESS stocke tout ça quelque part ! Mais ou ?

Je tourne en rond dans mon bocal !

C'est la première fois qu'ACCESS "récalcitre" de la sorte. Ma santé mentale se dégrade... A l'aide !

Bonne journée à tous.

Gégé

Liste des variables pour gestion d'erreur

16 réponses

Discussions similaires