Erreur 13 résistanteRésolu

Question

Bonjour,

Je développe une application sur Excel avec comme interface des formes et évidemment du VBA, L'utilitaire peut  RAZ (Remettre les formulaires vierges) les données lorsqu'on change de client.

Avant de procéder à la RAZ par une fonction d'effacement des données, mon application fonctionne très bien.
J'en suis donc à l'étape de déboger toutes les divisions par 0, "",  erreurs #N/A etc que provoque un effacement de données.

L'erreur 13 est un classique dont je pensais facilement m'affranchir ... mais là je donne ma langue au chat!

Quand j'ouvre mon formulaire en état "vièrge" il me paraît logique de mettre sous conditions toutes les lignes de code non pertinentes pour qu'elles ne s'executent pas.


Sur ma feuille Excel j'ai créé une cellule de vérification:


=ESTERREUR(L79)     En mode "vièrge" la cellule L79 ayant l'erreur #N/A j'ai donc VRAI en réponse à ma fonction.

Dans mon code VBA ma condition est:

 If Feuil27.Range("Tx_Ajust_Erreur") = False Then

Sur cette ligne de code j'ai une ERREUR 13 mais étrangement si je passe à True ca passe sans problème!!!

Pour le gros malins qui pensent déjà me répondre laisse le à True et met tes lignes après un Else j'ai une mauvaise nouvelle:

If Feuil27.Range("Tx_Ajust_Erreur") = True Then génère de nouveau une ERREUR 13

Étrange et agacant non? Si  quelqu'un a déjà vu ça ou a une alternative

PS: J'ai essayé bien d'autres trucs dont par exemple de déclarer une variable, ensuite variable = feuil27.... et enfin utiliser la variable dans la condition plutôt que la référence directe à la cellule ... mais niet 

Merci par avance

us_30 · Accepted Answer

Bonjour,


Le jeu subtile des erreurs est toujours un petit casse tête. IL me semble tout de même que tu sembles ne pas faire de différence entre les erreurs d'EXCEL (le tableur) et les erreurs du code de VB.


EXCEL et VBE, ont chacun leur propre code d'erreur. Là où cela devient très subtil, c'est que VBE détecte les erreurs du tableur EXCEL, et stoppe (en général) l'éxécution du code, comme si l'erreur venait du code. C'est subtil, car toujours un peu complexe à interprêter. 


Pour illustrer ceci, un exemple pour expérimentation pour voir comment cela fonctionne :


Ecrit dans la cellule "B4", la formule : =RECHERCHE(3;D3:D23)
Cette formule étant mal paramètrées, elle renvoit #N/A

Dans VBE, sur un module, copie le code :

Sub es()
Debug.Print Range("b4") 'affiche l'erreur renvoyée d'Excel dans l'éditeur => ce n'est pas du texte, mais un code d'erreur !
'MsgBox Range("b4") 'déclenche Erreur 13 car VBA reconnait l'erreur de la cellule
Debug.Print Err 'Err contient l'erreur courante du VBA
End Sub

et dans VBE, affiche la fenêtre d'eécution "CTRL+G", puis lance es() (positionne le curseur dans le code puis "F5").

Il s'affichera :
Erreur 2042
0

Erreur 2042 : correspond à la valeur de l'erreur renvoyé par le tableur Excel
0 : Code de l'erreur renvoyé par VBA

Maintenant, enlève à la deuxième ligne de code devant Msgbox, la commande Rem ( ' )
Puis recommence...

Là VBA s'arrête directement ! car avec Msgbox tu demandes d'utiliser le contenu actif de la cellule B4, or ce contenu est une erreur ! donc VBA s'arrête sur l'erreur ! (comme pour toute les erreurs, du reste). L'erreur renvoyé par VBA sera l'erreur 13 ! (alors que l'erreur du tableur est 2042, soit redit en passant)

Bon. Maintenant si on fait finalement ce que tu as fait, c'est à dire corrigé l'erreur en remettant Rem ( comprendre " ' " ) devant Msgbox, l'affichage de Err sera bien évidemment 13. Ceci pour dire qu'on pourrait cette valeur (13) pour la suite... mais c'est en temps réel, en quelque sorte... donc possible qu'avec la manipulation précédente...

Donc il s'affichera :
Erreur 2042
   (après Rem)
13

Moralité : Tout ceci pour dire qu'il ne faut pas d'erreur dans le tableur en général, pour exécuter correctement un code VBA...

Euh... oui aussi, tu aura compris que ON ERROR RESUME NEXT, n'a pas d'effet... puisque l'erreur du tableur ne change pas l'erreur du VBA (affichable avec Err, qui reste à zéro)...

Leçon à retenir : Les erreurs du tableur, ne sont pas les mêmes que ceux du VBA !

En espérant avoir éclairçi le truc qui se passe...

Amicalement,
Us.

cs_Jack · Answer

Salut
Quand ta feuille est vierge, il semble évident que tu n'as pas besoin de faire les calculs.
Je pense qu'il faudrait demander à Excel de stopper toutes les évaluations.
Voir onglet "Calcul" dans les "Options" : "Sur ordre"
Il suffira de remettre sur "Automatique" quand tes données seront cohérentes.

Vala
Jack, MVP VB
NB : Je ne répondrai pas aux messages privés

<hr />Le savoir est la seule matière qui s'accroit quand on la partage (Socrate)

cs_Nulll · Answer

Hmmmmm, je vais y réfléchir car comme il y a beaucoup d'heures de code je ne voudrais pas me relancer dans une refonte du processus. Quand on tire sur un bout de ficelle de la pelote on ne sait pas où et comment cela fini. Je vais garder ta solution en option au cas où personne n'est capable d'expliquer le phénomène.

J'ai cru avoir trouvé quand, dans la base de donnée de Microsoft ils disaient qu'il y avait un bug dans Microsoft office 2002 et qu'il fallait télécharger sp3. Avant de modifier quoi que ce soit j'ai testé sur mon autre PC monté avec Office 2007 (et en changeant le fichier en xlms). Le problème est toujours là.

Mais pourquoi diable lorsque on demande de comparer deux variables identiques (int à int, Bool à Bool, etc (et j'en suis sûr))  dans une alternative de réponse cela passe et dans l'autre j'ai l'erreur??????

20 mn plus tard

Tout en regardant ta solution je me suis livré à un autre test (en partant de ma feuille d'origine (non effacée) et en y allant pas à pas. Résultat, il semblerait que dès qu'il y a une cellule affectée de l'erreur #N/A, même si elle n'est pas liée à mon code conditionel VBA, ca plante. Je vais donc réécrire la fonction dans les cellules concernées pour que cette erreur n'apparaisse plus.

Vous-ai je dis que On Error Resume Next n'avait aucun effet???

Je ne vais pas tout de suite cocher sur résolu car j'aimerais tout de même connaître le fond du problème

Merci

Kristof_Koder · Answer

L'erreur 13 ne serait-elle pas une erreur d'objet non instancié par hasard ?
Auquel cas, soit Feuil27 n'existe pas dans le classeur soit aucune celulle nommée "Tx_Ajust_Erreur" n'ets présente sur cette feuille.

cs_Nulll · Answer

Comme je le supposais dans ma réponse à Jack, je viens de me débarrasser du problème en mettant une condition dans la cellule à l'origine du #N/A. Sa fonction initiale était RECHERCHE( ) pour m'extraire le pourcentage correspondant à une variable entrée (et effacée quand remis vierge). Cette liste se trouvait sur une autre feuille. J'ai donc inséré ma fonction dans une fonction SI qui détecte si la cellule variable est vide et dans ce cas affecte alors la valeur 0 au lieu de lancer la fonction RECHERCHE. Depuis ca roule! Ce qui est étonnant c'est que cette erreur qui est cirsonscrite à une cellule lorsqu'on regarde la feuille, semble affecter toutes les comparaisons dans mon code VBA même si on ne se réfère pas à cette cellule.


Pour ma culture si quelqu'un est capable de m'expliquer le comment du pourquoi de la logique Microsoft qui se cache derrière cela ...


Merci pour votre soutien à vous deux

cs_Nulll · Answer

Message et explications reçues et comprises 5/5 us_30! 

Merci encore à tout ceux qui m'ont donné leur avis.

Dorénavant, dans mon débugage, je serai beaucoup plus attentif aux cas de figures qui génèrent des erreurs dans mes feuilles Excel avant de perdre des heures à triturer mon code VBE.

Erreur 13 résistante

6 réponses

Votre réponse

Discussions similaires