Code VBA qui ne s'exécute correctement que quand la fenêtre debug est ouverte !

Version imprimable

16/08/2018, 11h52
JIM77420

1 pièce(s) jointe(s)

Code VBA qui ne s'exécute correctement que quand la fenêtre debug est ouverte !

Bonjour,

sur Excel2010 j'ai développé un programme qui, à partir d'un TCD qui pointe sur un tableau ou il y a des liens hypertexte, permet de récupérer les liens concernés dans l'onglet de détail généré par le double click d'une cellule dans le TCD. Le programme fonctionne correctement, mais lors des premières utilisations il y a un message d'erreur '5' : 'Argument ou Appel de procédure incorrect' avec la possibilité de débogage. mais l'instruction pointée

Code:

No_Onglet = CLng(Right(Sh.CodeName, Len(Sh.CodeName) - 5))

passait sans aucun problème avec un F8 et, après deux ou trois blocages avec cette erreur, il n'y avait plus de problème !
J'ai essayé plusieurs solutions trouvées sur le net, mais j'ai finalement mis un "on error resume next" devant la ligne et dupliqué la ligne incriminée et ça fonctionne bien.
J'ai ensuite eu un blocage avec le choix "continue" et pas d'erreur en pas à pas sur la ligne :

Code:

With Wb.VBProject.VBComponents(Feuille_Travail).CodeModule.InsertLines Lig, "Private Sub Worksheet_BeforeDoubleClick(ByVal Target As Range, Cancel As Boolean)": Lig = Lig + 1

que j'ai résolu en positionnant le paramètre

Code:

Application.EnableCancelKey = xlDisabled

Maintenant mon dernier problème en date est que le programme s'exécute, mais la feuille créée ne contient pas de code sauf quand j'ouvre la fenêtre debug et alors l'exécution est complète et tout se passe bien !
(les instructions utilisées sont, selon internet, "sensibles" au mode pas à pas et donc pas faciles à déboger!)

Toute cette longue présentation pour mettre en évidence les blocages d'exécution du VBA d'Excel2010 sans vrai motif qui m'ont fait perdre beaucoup de temps.

Je joins le code du sous programme concerné par ce problème, car je ne sais plus quoi faire pour l'utilisateur final de ce programme ait le moins de soucis possible !

Je vous remercie d'avoir lu ce post jusqu'à la fin et pour toute l'aide et les conseils que vous pourrez me prodiguer.

Cordialement,
Jim77420
23/08/2018, 11h23
Pierre Fauconnier

1 pièce(s) jointe(s)
Salut.

Je ne comprends pas bien l'intérêt d'injecter du code par vba ^^

Pour ce qui est du problème d'exécution en pas à pas etc...

Il faut savoir que On Error Resume Next et On Error Goto XXX gèrent l'erreur si et seulement si les options de l'éditeur le permettent.

Pièce jointe 405915
- Arrêt sur toutes les erreurs: Arrêt même si une gestion d'erreur est placée (ça permet de ne pas devoir décommenter la gestion d'erreurs en phase de tests;
- Arrêt dans le module de classe: Arrêt uniquement dans le code d'un module de classe si erreur au sein de ce code, malgré la gestion d'erreurs;
- Arrêt sur les erreurs non gérées: Arrêt uniquement sur les erreurs non gérées (pas de On Error Goto xxx et après un On Error Goto 0).
Donc, mettre une gestion d'erreur n'évite pas d'entrer en débogage car la gestion d'erreur dépend du On Error... mais aussi de l'option de l'éditeur.

Or... Vous ne contrôlez pas cette option chez les utilisateurs de vos solutions ==>>> On ne peut pas "programmer par la gestion d'erreurs"!!

Le souci du on error resume next, c'est que tu ne vois plus l'erreur.

Pour ton premier message d'erreur je te conseille d'essayer de comprendre ce qui se passe avec
Code:

1 2 3 4 5 6 7 8 9 On error resume next if false and No_Onglet = CLng(Right(Sh.CodeName, Len(Sh.CodeName) - 5)) then 'test faux, on n'entre ici que s'il y a une erreur d'exécution sur le reste du test debug.print sh.codeName stop else No_Onglet = CLng(Right(Sh.CodeName, Len(Sh.CodeName) - 5)) end if on error goto 0
Y a-t-il des feuilles qui ont été crées avec le nom Sheet9 et Feuil8 ? Ta macro devrait fonctionner avec les deux car cela fait bien 5 de longueur, mais au moment de reconstituer le nom de ta feuille, tu peux essayer d'adresser une feuille qui n'existe pas, ce qui expliquerait peut-être ton souci avec feuille_travail.

Ne trouvant pas la feuille, il ne peut pas trouver son module de code et ne peut pas écrire dedans.

Pourquoi cela fonctionnerait mieux en mode débug ? En général parce qu'à un endroit ou un autre, tu ne fais pas pareil, en général avec activate ou select. Si tu n'utilise aucun active workbook/sheet/cell, si tu n'utilises ni activate ni select (ni formule qui utilise une telle notion telle que 'cellule("ligne")'), c'est étrange que tu aies un fonctionnement différent. Si tu en as, à chaque ligne en jaune, tu réactives tout ce qui est actif et le redéfini en exécutant ton code.

A l'intuition, je dirais que résoudre ton tout premier problème les résoudra tous, et que tu as un objet dont le nom a a une longueur de plus de 5 de longueur, du coup, quand tu essaies de le récupérer, il y a une lettre qui est refusée par clng. Il faut trouver ce nom et prévoir le cas où tu es dessus.

J'avais répondu sur l'autre sujet que tu as ouvert pour la même chose, il n'y avait donc pas le txt.
https://www.developpez.net/forums/d1.../#post10534693 à fermer donc pour doublon.
Code:

1 2 3 4 5 6 7 8 Sh.Activate Sh.Select Debug.Print Sh.Name & " " & Sh.CodeName 'traitement du blocage de la commande ci-dessous On Error Resume Next No_Onglet = CLng(Right(Sh.CodeName, Len(Sh.CodeName) - 5)) No_Onglet = CLng(Right(Sh.CodeName, Len(Sh.CodeName) - 5))
C'est exactement ce que je disais, il y a des objets implicitement sur des objets actifs (sheets quelque chose est en fait implicitement activeworkbook.sheets la même chose).
Code:

1 2 Feuille_Travail = "Feuil" & No_Onglet
si ça se trouve, ton objet ne s'appelle pas Feuil mais Sheet

Ensuite, Est-ce que feuille_travail est bien une variable globale, existe t elle bien encore dans la sub ajoutCode.

Comme le dit pierre fauconnier, évite on error resume next, et résouds les soucis, surtout lorsque tu n'es pas encore à l'aise avec le vba.

15/10/2018, 14h24
Gfacro

Citation:

Envoyé par Pierre Fauconnier

Salut.

Je ne comprends pas bien l'intérêt d'injecter du code par vba ^^

Il y a quelques années, j'avais fait un outil pour gérer des équipes de personnes, une feuille par équipe, avec macro.
Dans mon cas, le code était le même pour toutes les équipes, ce qui était spécifique était par formule pour être plus facilement modifiable par des non informaticien. Mais on peut être amené à manipuler le code des feuilles produits s'il y a des spécificités de code.
Cela permet de conserver le module commun bien commun et que les modifications qui sont faites dedans se reportent dans les feuilles produites. Que l'injection de code soit spécifique (ou la modification de code) pour répondre aux spécificités de chaque document.

Ce n'était pas le cas que j'ai eu, mais si le code a des spécificités selon divers critères à croiser, le plus simple est de d'injecter le code spécifique par code plutôt que de multiplier les modules dans chaque cas.

Exemple : équipe capable de parler anglais, équipe capable de se déplacer sur site, équipe capable d'avoir telle spécificité, ... Plutôt que de multiplier le code, de croiser les critères : en avoir un général et le spécialiser selon le besoin.
15/10/2018, 15h40
Pierre Fauconnier

Citation:

Envoyé par Gfacro

[...]

il n'y a aucune justification technique à devoir modifier le code par vba. Ce besoin résulte toujours d'un défaut de conception/architecture. De plus, l'injection de code n'est possible que si une option de sécurité est cochée sur le poste de l'utilisateur, et l'utilisateur est bien entendu toujours libre de ne pas accepter de cocher cette case, qui ouvrirait une brèche de sécurité.

Citation:

Envoyé par Gfacro

Le souci du on error resume next, c'est que tu ne vois plus l'erreur.[...]

Ce n'est pas exact. Ca dépend, comme je l'illustre, de l'option choisie pour la gestion des erreurs, et donc des options sur le poste de l'utilisateur.

Pour éviter ce genre de problème, il faut éviter d'adresser les feuilles directement et travailler avec des objets de type Worksheet renvoyés par une fonction getWorksheetByCodeName par exemple. Si la fonction renvoie une feuille valide, on continue, sinon on arrête. Travailler de cette manière permet d'éviter les On Error qui ne devraient être utilisés que pour le code exécuté sur lequel on n'a pas le contrôle.