Erreur macro
Lyly601
Messages postés
67
Date d'inscription
jeudi 5 janvier 2006
Statut
Membre
Dernière intervention
16 octobre 2006
-
3 févr. 2006 à 15:21
ScSami Messages postés 1488 Date d'inscription mercredi 5 février 2003 Statut Membre Dernière intervention 3 décembre 2007 - 4 févr. 2006 à 18:33
ScSami Messages postés 1488 Date d'inscription mercredi 5 février 2003 Statut Membre Dernière intervention 3 décembre 2007 - 4 févr. 2006 à 18:33
2 réponses
jannoman
Messages postés
256
Date d'inscription
jeudi 17 avril 2003
Statut
Membre
Dernière intervention
20 février 2008
1
3 févr. 2006 à 15:52
3 févr. 2006 à 15:52
ben t'as qu'a faire:
si cellule() est vide alors exit sub
A+.
Thomas.
si cellule() est vide alors exit sub
A+.
Thomas.
ScSami
Messages postés
1488
Date d'inscription
mercredi 5 février 2003
Statut
Membre
Dernière intervention
3 décembre 2007
24
4 févr. 2006 à 18:33
4 févr. 2006 à 18:33
A quoi correspondent les accronyme "UC" et "UM" ??? UM = Palette mais pourquoi donc "UM" ???? (c'est le genre de truc qui va m'empêcher de dormir )
Alors, déjà, permet moi de te sermoner un instant... Evite de donner des noms accentués (a tes variables, procédures, ...). Préfère l'écriture "Call maProcedure" à simplement "maProcedure" car ainsi on sait que c'est un appel et pas une "faute" sur une variable! Pense également à indenter
ton code
(niveler par des retraits de marge).
Bon, voilà, je crois qu'on a fait le tour des deux trois petits trucs qui m'embêtait.
Comme à dit Tom, il faut, soit :
- Préalablement testé la viabilité des cellules utilisées dans les calculs
- Gerer l'erreur selon, me semble-t-il, 2 techniques différentes
Donc, au début de ta proc Command1_Click, il faut tester la viabilité de tes cellules via des If (éventuellement mis dans une boucle s'il y a beaucoup de cellules à tester). Tu peux soit, basiquement (mais c'est pas "pro", sécuritaire), comparer avec { ="" } ou alors, en utilisant une fonction style IsNumeric & cie. Bref, si une cellule n'est pas valide, tu peux, selon son état d'invalidité, afficher ou non un message d'alerte (évite d'en afficher un pour les cellules vides parce que ce sera rapidement pénible pour l'utilisateur! En revanche, si tu attends des nombres et que l'utilisateur entre des alphas, il faut l'informer des valeurs que peut prendre cellule [ici, en l'occurence, des nombres!]). Ensuite, il faut avorter la procédure en la quittant via Exit Sub.
Ceci n'empêche en rien d'instaurer un gestionnaire d'erreur! C'est, en effet, important si tu utilises des calculs mathématiques sans être certain des valeurs des cellules (oui, par exemple, certaines fonctions de calcul n'accepte qu'un certain type de donnée sans quoi elle génère un message d'erreur!).
La première technique que je te déconseille mais qui est la plus "simple" pour "corriger" ton "bug", est d'utiliser un If avant de faire le calcul. Tu teste la valeur de NbPiecePalette et si elle est mauvaise (= à 0), bien soit tu sorts de la procédure via Exit Sub, soit de te contente simplement de ne pas faire le calcul. Dans ce dernier cas, évidemment, il te faudra placer ta division dans ce If (cf. End If ).
Mais le mieux reste quand même le gestionnaire d'erreur de VB.
Ta procédure doit (et toute procédure/fonction si tu veux un programme fiable!) contenir une structure de ce type :
Sub maProcedure()
On Error Goto GestionDesErreurs
...
...
...
Exit Sub
GestionDesErreurs:
...
End Sub
(les "..." étant tes instructions!)
Autrement dit, dès qu'une erreur se produira, l'exécution de ta macro va basculer vers le point GestionDesErreurs. C'est donc une sorte de "disjoncteur".
Dans le bloc GestionDesErreurs tu mets ce que tu veux. Généralement on met un message précisant qu'il y a eu une erreur, le numéro de cette dernière (Err.Number) et sa description interne [celle du VB] (Err.Description).
Mais cette structure permet également d'adapter les messages d'erreurs en fonction de la source du problème (si tu t'es donné la peinne de placer une variable devant chaque grande phase...).
Bref, je pense en avoir assez dit.
Est-ce que cela répond à ta question ?
Enjoy
<hr size="2" width="100%">
( Si une réponse vous convient, cliquez sur le bouton "Réponse acceptée". )
Alors, déjà, permet moi de te sermoner un instant... Evite de donner des noms accentués (a tes variables, procédures, ...). Préfère l'écriture "Call maProcedure" à simplement "maProcedure" car ainsi on sait que c'est un appel et pas une "faute" sur une variable! Pense également à indenter
ton code
(niveler par des retraits de marge).
Bon, voilà, je crois qu'on a fait le tour des deux trois petits trucs qui m'embêtait.
Comme à dit Tom, il faut, soit :
- Préalablement testé la viabilité des cellules utilisées dans les calculs
- Gerer l'erreur selon, me semble-t-il, 2 techniques différentes
Donc, au début de ta proc Command1_Click, il faut tester la viabilité de tes cellules via des If (éventuellement mis dans une boucle s'il y a beaucoup de cellules à tester). Tu peux soit, basiquement (mais c'est pas "pro", sécuritaire), comparer avec { ="" } ou alors, en utilisant une fonction style IsNumeric & cie. Bref, si une cellule n'est pas valide, tu peux, selon son état d'invalidité, afficher ou non un message d'alerte (évite d'en afficher un pour les cellules vides parce que ce sera rapidement pénible pour l'utilisateur! En revanche, si tu attends des nombres et que l'utilisateur entre des alphas, il faut l'informer des valeurs que peut prendre cellule [ici, en l'occurence, des nombres!]). Ensuite, il faut avorter la procédure en la quittant via Exit Sub.
Ceci n'empêche en rien d'instaurer un gestionnaire d'erreur! C'est, en effet, important si tu utilises des calculs mathématiques sans être certain des valeurs des cellules (oui, par exemple, certaines fonctions de calcul n'accepte qu'un certain type de donnée sans quoi elle génère un message d'erreur!).
La première technique que je te déconseille mais qui est la plus "simple" pour "corriger" ton "bug", est d'utiliser un If avant de faire le calcul. Tu teste la valeur de NbPiecePalette et si elle est mauvaise (= à 0), bien soit tu sorts de la procédure via Exit Sub, soit de te contente simplement de ne pas faire le calcul. Dans ce dernier cas, évidemment, il te faudra placer ta division dans ce If (cf. End If ).
Mais le mieux reste quand même le gestionnaire d'erreur de VB.
Ta procédure doit (et toute procédure/fonction si tu veux un programme fiable!) contenir une structure de ce type :
Sub maProcedure()
On Error Goto GestionDesErreurs
...
...
...
Exit Sub
GestionDesErreurs:
...
End Sub
(les "..." étant tes instructions!)
Autrement dit, dès qu'une erreur se produira, l'exécution de ta macro va basculer vers le point GestionDesErreurs. C'est donc une sorte de "disjoncteur".
Dans le bloc GestionDesErreurs tu mets ce que tu veux. Généralement on met un message précisant qu'il y a eu une erreur, le numéro de cette dernière (Err.Number) et sa description interne [celle du VB] (Err.Description).
Mais cette structure permet également d'adapter les messages d'erreurs en fonction de la source du problème (si tu t'es donné la peinne de placer une variable devant chaque grande phase...).
Bref, je pense en avoir assez dit.
Est-ce que cela répond à ta question ?
Enjoy
<hr size="2" width="100%">
( Si une réponse vous convient, cliquez sur le bouton "Réponse acceptée". )