Discussion :

[ThatIsMe]

Bonjour à tous,
Je galère depuis pass mal de temps à cause de plantages réguliers du compilateur VBA (sous EXCEL). Lorsque je lance la compilation ("Débogage / Compiler VBAProject"), régulièrement, mais pas systématiquement, le compilateur se plante, n'arrive pas au bout du débogage ; tout se fige, et je suis obligé de tuer EXCEL avec le gestionnaire des tâches.
Si les macros étaient activées, je suis obligé de renommer le fichier, puis de le réouvrir sans activer les macros, et là, la compilation refonctionne. Mais le problème se repose régulièrement après des modifications du code. Cela me fait perdre un temps fou.
Quelqu'un a-t-il déjà rencontré (par malheur) ce problème et trouvé (par bonheur) la solution ?
J'ai rencontré le même problème avec plusieurs versions de Windows (7, 8, 10 et 11) et avec plusieurs versions d"EXCEL (2010, 2016 et 2019). NB : bien entendu, tout ceci n'arrivait pas avec Windows XP et EXCEL 97 ...
Merci de votre secours.

[mjpmjp]

bonjour,
as tu essayé sur un autre PC ? , peut être envisager une réinstallation d'Excel
@+JP

[ThatIsMe]

bonjour,
as tu essayé sur un autre PC ? , peut être envisager une réinstallation d'Excel
@+JP

Bonjour,
Oui, j'ai essayé sur plusieurs PC (pro et perso), et j'ai réinstallé pas mal de fois EXCEL, dans plusieurs versions. Cela ne vient pas de là.
Merci

[jurassic pork]

hello,
est-ce qu'il y a le problème quelque soit le classeur et quelque soit les macros qui sont à l'intérieur ?
Ami calmant, J.P

[ThatIsMe]

hello,
est-ce qu'il y a le problème quelque soit le classeur et quelque soit les macros qui sont à l'intérieur ?
Ami calmant, J.P

Bonjour,
Non, cela n'arrive que sur des classeurs avec des "grosses" macros, heureusement. Mais je ne sais pas à partir de quelle "grosseur" ...
Merci

[mjpmjp]

bonjour,
il y a très longtemps j'avais eu un problème "fantôme"
en fait j' avais extrais , ou copié (je sais plus) tous les éléments page , module ...
pour repartir avec un autre fichier tout neuf

@+JP

[Pierre Fauconnier]

Salut.

Réinstaller Excel ne doit être réalisé qu'en dernière extrémité.

Lorsque ça plante sur un fichier et pas sur d'autres, c'est probablement plus le fichier qui est en cause qu'Excel. Cela dit, je ne sais pas ce tu veux dire par "grosse macro"... Ca veut dire beaucoup de macros ou des macros très longues?

Perso, j'analyserais le code et j'essaierais de le découper en petites fonctions/procédures très courtes qui ne font que quelques lignes et qui ne font surtout qu'une seule chose! J'éviterais les variables publiques, je scinderais mon code dans différents modules...

Bref, du taf...

[...]
J'ai rencontré le même problème avec plusieurs versions de Windows (7, 8, 10 et 11) et avec plusieurs versions d"EXCEL (2010, 2016 et 2019). NB : bien entendu, tout ceci n'arrivait pas avec Windows XP et EXCEL 97[...]

Peut-être faut-il travailler en Windows XP et en 97, alors... Je doute que tu sois gagnant, ceci dit... ==> Cela dit, si le fichier vient de XL97, voire même 2003, une refonte du code, et du fichier, serait à mon avis à revoir, ne serait-ce que pour utiliser les nouveaux outils tels que tableaux structurés, Power query... Le "vieux" code et la "vieille" conception de fichiers hérités de 2003 et antérieurs sont rarement un gage de stabilité et de bonnes pratiques.

[Pierre Fauconnier]

Cela dit, il faut bien s'entendre sur les termes...

Tu parles de plantage du compilateur... Es-tu sûr que c'est à la compilation que ça plante? Ne serait-ce pas plutôt à l'exécution du code?

[Doatyn]

Si c'est un fichier ancien, il faut peut-être le convertir en xml (enregistrer sous > .xlsm)

[fouziel]

Bonjour
J'ai le même type de problème depuis des années, je suis sous Office 365 maintenant, ce plantage m'est arrivé avec d'autres versions d'Excel. Je suis convaincu maintenant qu'Excel enregistre quelque part (mais allez savoir où) des informations réutilisées lors des exécutions suivantes. Si ces informations sont alterrées (pourquoi je ne sais pas ...) impossible de les regénérer faciement (il ne s'agit pas là simplement de recompiler). Pour preuve qye des informations sont sauvegardées dans le fichier Excel, celui-ci grossit à chaque fois que je le sauvegarde, même si je n'ai fait aucune modification de code ou de data.

La seule manip qui me sauve à chaque fois consiste à recréer mon fichier .xlsm en exportant et réimportant tous les modules présents dans le fichier source.
Pour réaliser cela rapidement (j'ai une gestion de planification / plan de charge analytique qui contient près d'une centaine de modules maintenant), j'ai développé une fonction d'export / import de ces modules, classes, formulaires, etc ...

Je serais preneur de vos lumières messieurs/ dames les expert.e.s !

Bien Cordialement
Franck

[Doatyn]

Excel a parfois des difficultés avec des références externes de type "Public Declare Function". Si "l'adversaire" ne réponds pas, il peut ne rien faire en attendant la réponse. Ou peut être avec un .xlsa.
Il y a un aussi un sujet que je n'ai jamais su résoudre avec VBA : Excel a visiblement des "états de fonctionnement", qui par exemple empêche l'ouverture d'un autre fichier tant qu'on est en train d'éditer une cellule.
Il faut aussi faire attention à ne jamais nommer une procédure du même nom qu'un module ou un CodeName de feuille.
Et comme dit Valtrase, utiliser sans modération Option Explicit, et DoEvents (permettant d'interrompre l'exécution avec CtrlPause pour détecter les boucles infinies).

[fouziel]

Excel a parfois des difficultés avec des références externes de type "Public Declare Function". Si "l'adversaire" ne réponds pas, il peut ne rien faire en attendant la réponse. Ou peut être avec un .xlsa.
Il y a un aussi un sujet que je n'ai jamais su résoudre avec VBA : Excel a visiblement des "états de fonctionnement", qui par exemple empêche l'ouverture d'un autre fichier tant qu'on est en train d'éditer une cellule.
Il faut aussi faire attention à ne jamais nommer une procédure du même nom qu'un module ou un CodeName de feuille.
Et comme dit Valtrase, utiliser sans modération Option Explicit, et DoEvents (permettant d'interrompre l'exécution avec CtrlPause pour détecter les boucles infinies).

Bonjour et merci pour ta réponse Doatyn,
Je suppose que tu fais référence à l'appel d'API externes type API windows par exemple. Pour ma part, je me suis interdit de les utiliser pour rester sur du "standard" Excel et permettre une compatibilité 100% avec VBA sur MAC ... (j'ai galéré car il y a de nombreuses autres incompatibilités ...).

Je ne mélange jamais Datas et programmes, j'ai ainsi un classeur dédié différent contenant toutes mes macros capables de travailler sur un autre classeur ouvert (et facilitant sa conversion en .xlam).

J'applique à ma connaissance toutes les bests practices usuelles de la "bonne programmation" :
- usage du typage fort, 'option explicite' est une question d'hygiène chez moi,
- découpage du code en parties fonctionnelles, dans des modules dédiés,
- utilisation de classes et de classes factories
- limitation de l'usage de variables globales, mais j'en ai absolument besoin dans certains cas
- usage contrôlé de DoEvents (dans certains cas peut faire planter Excel en cas de réentrance !)
- usage parcimonique des interfaces (dommage que le vrai héritage n'existe pas sous VBA ...)
- Je documente comme je peux .... j'avoue ne pas être le meilleur des élèves de ce point de vue là ...
etc etc ... (40 ans de développement ça laisse des traces ...)

Je sais que les fichiers Excel sont en fait des fichiers au format Zip renommés. Connaissez-vous des outils qui permettent d'isdoler certaines parties du contenu de ces zip pour les écraser par exemple ? Si j'arrive à isoler les traces qu'Excel laisse dans mon fichier xlsm, peut-être aurais-je compris pour partie ce qui le fait planter voire même remplacer ces parties avant première exécution ?

Bref c'est un sujet qui me prend un peu la tête car je n'ai pas trouvé de solution qui fonctionne à 100%, cela fait pourtant des années que je cherche.

Merci de vos retours.

Franck

[jurassic pork]

Hello,

J'ai le même type de problème depuis des années, je suis sous Office 365 maintenant, ce plantage m'est arrivé avec d'autres versions d'Excel. Je suis convaincu maintenant qu'Excel enregistre quelque part (mais allez savoir où) des informations réutilisées lors des exécutions suivantes. Si ces informations sont alterrées (pourquoi je ne sais pas ...) impossible de les regénérer faciement (il ne s'agit pas là simplement de recompiler). Pour preuve qye des informations sont sauvegardées dans le fichier Excel, celui-ci grossit à chaque fois que je le sauvegarde, même si je n'ai fait aucune modification de code ou de data.
La seule manip qui me sauve à chaque fois consiste à recréer mon fichier .xlsm en exportant et réimportant tous les modules présents dans le fichier source.

Avec un logiciel comme 7zip tu peux voir l'intérieur des fichiers xlsm et voir la taille des différents fichiers qui sont dedans.
Exemple :

7-Zip 19.00 (x64) : Copyright (c) 1999-2018 Igor Pavlov : 2019-02-21
Scanning the drive for archives:
1 file, 13935 bytes (14 KiB)
Listing archive: testRuban.xlsm


Date Time Attr Size Compressed Name
------------------- ----- ------------ ------------ ------------------------
1980-01-01 00:00:00 ..... 1087 367 [Content_Types].xml
1980-01-01 00:00:00 ..... 736 297 _rels\.rels
1980-01-01 00:00:00 ..... 2173 906 xl\workbook.xml
1980-01-01 00:00:00 ..... 679 260 xl\_rels\workbook.xml.rels
1980-01-01 00:00:00 ..... 978 533 xl\worksheets\sheet1.xml
1980-01-01 00:00:00 ..... 8391 1880 xl\theme\theme1.xml
1980-01-01 00:00:00 ..... 1618 676 xl\styles.xml
1980-01-01 00:00:00 ..... 14336 4666 xl\vbaProject.bin
1980-01-01 00:00:00 ..... 597 319 docProps\core.xml
1980-01-01 00:00:00 ..... 793 395 docProps\app.xml
1980-01-01 00:00:00 ..... 522 522 customUI\customUI.xml
------------------- ----- ------------ ------------ ------------------------
1980-01-01 00:00:00 31910 10821 11 files

Sachant que xl\vbaProject.bin est un fichier binaire qui contient tout ce qui concerne le VBA


Quand ton fichier xlsm grossit à chaque sauvegarde regarde avec 7zip quel est le fichier qui grossit à l'intérieur.
Pour ouvrir un fichier avec xlsm : cliquer droit / ouvrir avec 7zip File Manager (7zFM).Bien sûr il faut au préalable que 7zip soit installé sur l'ordinateur.
As-tu des macros qui s'exécutent à l'ouverture et à la fermeture du classeur ?


Ne pas oublier non plus qu'il y a une option de vérification et de réparation dans l'ouverture des fichiers avec Excel.




Ami calmant, J.P

[fouziel]

Hello,

Avec un logiciel comme 7zip tu peux voir l'intérieur des fichiers xlsm et voir la taille des différents fichiers qui sont dedans.
Exemple :


Sachant que xl\vbaProject.bin est un fichier binaire qui contient tout ce qui concerne le VBA


Quand ton fichier xlsm grossit à chaque sauvegarde regarde avec 7zip quel est le fichier qui grossit à l'intérieur.
Pour ouvrir un fichier avec xlsm : cliquer droit / ouvrir avec 7zip File Manager (7zFM).Bien sûr il faut au préalable que 7zip soit installé sur l'ordinateur.
As-tu des macros qui s'exécutent à l'ouverture et à la fermeture du classeur ?


Ne pas oublier non plus qu'il y a une option de vérification et de réparation dans l'ouverture des fichiers avec Excel.




Ami calmant, J.P

Merci je vais regarder tout cela !

[papyjac]

Bonjour à tous,
Je galère depuis passe mal de temps à cause de plantages réguliers du compilateur VBA (sous EXCEL). Lorsque je lance la compilation ("Débogage / Compiler VBAProject"), régulièrement, mais pas systématiquement, le compilateur se plante, n'arrive pas au bout du débogage ; tout se fige, et je suis obligé de tuer EXCEL avec le gestionnaire des tâches.
...

J'ai eu précisément des plantages du compilateur sur mon dernier développement en macro (extension xlsm)
j'ai finis par me rendre compte que le problème venait de mes dimensions de tableaux, car en réduisant le problème a disparu, et en augmentant le problème revient
je n'ai pas de certitude

Tableau1(37200) ça marche
Tableau2(100000) ça marche
Tableau3(10000, 10000) ça plante le compilateur
Tableau4(9000, 9000) ça marche

c'est un plus complexe car cela dépend aussi du nombre de tableaux
par exemple :
3 Tableaux(10000, 10000) ça marche
4 Tableaux(10000, 10000) ça plante le compilateur

du coup je peux poursuivre mon développement actuel (jeu de la vie de conway)

[fouziel]

J'ai eu précisément des plantages du compilateur sur mon dernier développement en macro (extension xlsm)
j'ai finis par me rendre compte que le problème venait de mes dimensions de tableaux, car en réduisant le problème a disparu, et en augmentant le problème revient
je n'ai pas de certitude

Tableau1(37200) ça marche
Tableau2(100000) ça marche
Tableau3(10000, 10000) ça plante le compilateur
Tableau4(9000, 9000) ça marche

c'est un plus complexe car cela dépend aussi du nombre de tableaux
par exemple :
3 Tableaux(10000, 10000) ça marche
4 Tableaux(10000, 10000) ça plante le compilateur

du coup je peux poursuivre mon développement actuel (jeu de la vie de conway)

Bonjour
Parmi les causes de déstabilisation du compilateur que j'ai pu observer, la taille des allocations de tableau tient sa place en effet.
Mais il y en a d'autres :
- récursivité trop importante,
- DLL vba non à jour ...
- Appel à une fonction API native (via un Declare SUB) qui plante ...

Les formes de plantage sont diverses : à l'exécution ou à la compilation;
- Excel se ferme intempestivement ... au lancement de la macro ou à l'ouverture (je fais une réparation du fichier Excel dans ce cas)
- Excel se fige ...
- Le compilateur identifie de fausses erreurs (Sub ou Function non définie .... alors qu'elle l'est bien, et non cela n'est pas un pb de portée public ou privée ...)

Je règle temporairement ces problèmes de la manière suivante : j'exporte et ré-importe tous les modules, formulaires et classes.
En général, quand je le peux, je scinde mon développement en deux parties en isolant la partie code dans un classeur dédié (qui pourra ensuite devenir une extension ...) et le ou les classeurs contenant les données à manipuler. De cette manière je n'ai pas de reprise de données à traiter lorsque je regénère mon classeur contenant les macros.
J'ai aussi développé du code (succédané de DevOps ...) permettant cet export import automatique ...