Arrêt intempestif de procédures VBA
tessel75
-
tessel75 -
tessel75 -
Bonjour,
Je rencontre une difficulté avec plusieurs procédures VBA Excel au moment où je demande d'enregistrer le fichier sur lequel VBA a travaillé juste avant.
Càd que je lance la procédure, en fait un ensemble de plusieurs procédures successives, et elle s'arrête à la ligne commandant certain enregistrement, et alors propose le message habituel de choix entre arrêt définitif ou débugage.
Le problème est que la ligne de commande est correcte puisque qu'on peut relancer le cours de la procédure en question sans autre intervention qu'en cliquant sur l'icône "Pas à pas" puis "Pas à pas sortant" où il enchaîne les commandes sans plus s'arrêter.
Je ne comprends pas, parce que, comme il s'agit d'un ensemble de procédures un peu complexes, avec différentes étapes dans la mise en forme d'un tableau, j'ai prévu plusieurs enregistrements intermédiaires de sauvegarde à mesure que les étapes se déroulent, et qu'il bute toujours sur la même ligne mais de manière aléatoire, un jour oui et un jour non, tandis que les autres se passent sans difficultés. Et aussi parce que j'ai tout tenté, avec et sans arrêt volontaire sur une commande "SendKeys()", mais que cela ne change rien quant à ces arrêts intempestifs.
Plusieurs indications supplémentaires, si cela peut vous aider à comprendre ce qui arrive:
1) à ce passage, il faut écraser un fichier précédent du même nom, mais j'ai plusieurs autres procédures du même genre où l'arrêt ne se produit pas. Faudrait-il alors prévoir de supprimer ce fichier précédent avant d'enregistrer le nouveau, plutôt que l'écraser; mais cette solution est problématique.
2) ce n'est pas une question d'écriture de commande parce que j'en ai écrit plein d'autres du même type qui ne bloque pas, et comme j'ai dit la ligne en question passe normalement à condition de l'aider à la main, avec la commande "<ital>pas à pas<ital>" puis "<ital>pas à pas sortant<ital>"
Je vous remercie pour vos idées et votre aide parce que je dois quitter le service dans quelques semaines et que mes collègues sont bien incapables d'aller tripatouiller dans les modules VBA, et qu'en plus je préfère laisser des outils qui tournent bien que des machins qui plantent à moitié un jour sur deux.
Bien à vous. A vous lire en espérant avoir été clair.
Nota: je travaille avec Excel2003
Je rencontre une difficulté avec plusieurs procédures VBA Excel au moment où je demande d'enregistrer le fichier sur lequel VBA a travaillé juste avant.
Càd que je lance la procédure, en fait un ensemble de plusieurs procédures successives, et elle s'arrête à la ligne commandant certain enregistrement, et alors propose le message habituel de choix entre arrêt définitif ou débugage.
Le problème est que la ligne de commande est correcte puisque qu'on peut relancer le cours de la procédure en question sans autre intervention qu'en cliquant sur l'icône "Pas à pas" puis "Pas à pas sortant" où il enchaîne les commandes sans plus s'arrêter.
Je ne comprends pas, parce que, comme il s'agit d'un ensemble de procédures un peu complexes, avec différentes étapes dans la mise en forme d'un tableau, j'ai prévu plusieurs enregistrements intermédiaires de sauvegarde à mesure que les étapes se déroulent, et qu'il bute toujours sur la même ligne mais de manière aléatoire, un jour oui et un jour non, tandis que les autres se passent sans difficultés. Et aussi parce que j'ai tout tenté, avec et sans arrêt volontaire sur une commande "SendKeys()", mais que cela ne change rien quant à ces arrêts intempestifs.
Plusieurs indications supplémentaires, si cela peut vous aider à comprendre ce qui arrive:
1) à ce passage, il faut écraser un fichier précédent du même nom, mais j'ai plusieurs autres procédures du même genre où l'arrêt ne se produit pas. Faudrait-il alors prévoir de supprimer ce fichier précédent avant d'enregistrer le nouveau, plutôt que l'écraser; mais cette solution est problématique.
2) ce n'est pas une question d'écriture de commande parce que j'en ai écrit plein d'autres du même type qui ne bloque pas, et comme j'ai dit la ligne en question passe normalement à condition de l'aider à la main, avec la commande "<ital>pas à pas<ital>" puis "<ital>pas à pas sortant<ital>"
Je vous remercie pour vos idées et votre aide parce que je dois quitter le service dans quelques semaines et que mes collègues sont bien incapables d'aller tripatouiller dans les modules VBA, et qu'en plus je préfère laisser des outils qui tournent bien que des machins qui plantent à moitié un jour sur deux.
Bien à vous. A vous lire en espérant avoir été clair.
Nota: je travaille avec Excel2003
A voir également:
- Arrêt intempestif de procédures VBA
- Arrêt maladie - Guide
- L'indice n'appartient pas à la sélection vba - Forum VB / VBA
- La Sécurité sociale durcit les règles - Ces médecins ne pourront plus délivrer d'arrêt maladie - Guide
- Bouton marche arret i o - Forum Word
- Forcer arret application windows - Guide
3 réponses
Bonjour,
Sans fichier ni même une ligne de code ça va tenir de la divination...
On peut quand même supposer qu'il ne plante pas sans raison.
Vu qu'ensuite en pas à pas il passe, on peut supposer aussi qu'il va plus vite que la musique et que de contrôler que l'opération précédente est bien finie ou bien ajouter une tempo (moins bien) arrangerait les choses.
Les opérations I/O sont parfois assez lentes.
Faudrait-il alors prévoir de supprimer ce fichier précédent avant d'enregistrer le nouveau, plutôt que l'écraser; mais cette solution est problématique.
Je ne vois pas trop pourquoi ça serait problématique mais si tu penses que ça peut être la réponse il faut tester.
Renommer (et faire le ménage plus tard) sera plus rapide qu'une suppression passant par la corbeille.
eric
Sans fichier ni même une ligne de code ça va tenir de la divination...
On peut quand même supposer qu'il ne plante pas sans raison.
Vu qu'ensuite en pas à pas il passe, on peut supposer aussi qu'il va plus vite que la musique et que de contrôler que l'opération précédente est bien finie ou bien ajouter une tempo (moins bien) arrangerait les choses.
Les opérations I/O sont parfois assez lentes.
Faudrait-il alors prévoir de supprimer ce fichier précédent avant d'enregistrer le nouveau, plutôt que l'écraser; mais cette solution est problématique.
Je ne vois pas trop pourquoi ça serait problématique mais si tu penses que ça peut être la réponse il faut tester.
Renommer (et faire le ménage plus tard) sera plus rapide qu'une suppression passant par la corbeille.
eric
Bonjour,
Ce matin il n'y avait pas de marc dans le café : alors pas d'oracle ! ;-)
Tu nous dit que tu as fait des procédures dont la programmation est correcte mais qu'elles plantent de temps en temps. Comme l'on ne connais à peu près rien de ce que tu as fait comment veux-tu que l'on ai la moindre idée sur la raison de ton plantage (surtout sans marc de café !). Ce n'est sans doute pas tes suppositions qui sont en cause (écraser ou supprimer un fichier) mais ailleurs : sans doute que dans ta procédure il se produit un enchainement d'événements incorrects malgré ta certitude d'avoir réalisé un sans faute.
Ce matin il n'y avait pas de marc dans le café : alors pas d'oracle ! ;-)
Tu nous dit que tu as fait des procédures dont la programmation est correcte mais qu'elles plantent de temps en temps. Comme l'on ne connais à peu près rien de ce que tu as fait comment veux-tu que l'on ai la moindre idée sur la raison de ton plantage (surtout sans marc de café !). Ce n'est sans doute pas tes suppositions qui sont en cause (écraser ou supprimer un fichier) mais ailleurs : sans doute que dans ta procédure il se produit un enchainement d'événements incorrects malgré ta certitude d'avoir réalisé un sans faute.
Bonjour et merci à tous les deux,
Je ne vous avais pas délaissé mais j'étais en train de tester une version propre à être envoyée. Evidement elle marche impeccablement.
Il faut dire que la procédure qui pose problème est au boulot et inaccessible jusqu'à mardi.
Cela dit, je retiens surtout l'hypothèse d'Eric: "on peut supposer aussi qu'il va plus vite que la musique et que de contrôler que l'opération précédente est bien finie", parce que le test que je viens de refaire ici sur une machine relativement récente (2011) se passe parfaitement. Il faudra que tu me dises comment faire pour s'assurer que toutes les étapes précédentes sont bien achevées.
Un dernier point: la solution qui consiste à supprimer avant d'enregistrer plutôt qu'écraser me pose problème parce qu'il s'agit d'enregistrements mensuels qui s'ajoutent par paquet (environ 260) de lignes en lignes. Ecraser veut alors dire remplacer un fichier ancien par un nouveau mis à jour; tandis que supprimer veut dire que si le nouveau pose une difficulté à l'enregistrement, l'ancien est perdu sans que le nouveau soit disponible.
Encore Merci et à mardi soir donc.
Je ne vous avais pas délaissé mais j'étais en train de tester une version propre à être envoyée. Evidement elle marche impeccablement.
Il faut dire que la procédure qui pose problème est au boulot et inaccessible jusqu'à mardi.
Cela dit, je retiens surtout l'hypothèse d'Eric: "on peut supposer aussi qu'il va plus vite que la musique et que de contrôler que l'opération précédente est bien finie", parce que le test que je viens de refaire ici sur une machine relativement récente (2011) se passe parfaitement. Il faudra que tu me dises comment faire pour s'assurer que toutes les étapes précédentes sont bien achevées.
Un dernier point: la solution qui consiste à supprimer avant d'enregistrer plutôt qu'écraser me pose problème parce qu'il s'agit d'enregistrements mensuels qui s'ajoutent par paquet (environ 260) de lignes en lignes. Ecraser veut alors dire remplacer un fichier ancien par un nouveau mis à jour; tandis que supprimer veut dire que si le nouveau pose une difficulté à l'enregistrement, l'ancien est perdu sans que le nouveau soit disponible.
Encore Merci et à mardi soir donc.