Excel 2004 : problème à l'ouverture de classeur

[iluro_64]

Depuis que j'ai mis de côté Office v.X et partagé mes classeurs entre Excel 2004 et Excel 2008, selon qu'ils faisaient appel ou non à des macros, je suis confronté à un problème d'ouverture de fichiers classeurs Excel 2004 qui, à la longue m'énerve. Selon la façon dont se fait l'ouverture d'un modèle bien identifié de classeur, Excel 2004 se "crash" dès que la fenêtre qui s'ouvre pour l'activation ou non des macros est utilisée, tout aussi bien par le bouton " activation " que par le bouton " désactivation ".

Exposé du problème :

Après lancement de Excel 2004 (dernière mise à jour faite), l'ouverture d'un certain classeur, appelons-le Gestion, faisant appel à des macros, entraîne un "crash" d'Excel. Ce crash est systématique, que l'activation (ou la désactivation) des macros soit faite, ou non. Je précise que toutes les macros sont stockées dans un classeur unique dédié aux macros. Bien que marginal, ce problème est énervant à la longue, même s'il est facile à contourner.

Au cours du lancement, deux classeurs, sont systématiquement ouverts, l'un servant de modèle personnel, appelons-le Modèle, l'autre contenant toutes les macros, appelons-le Macros. Ces deux classeurs sont "masqués". Si l'un des deux classeurs masqués a été affiché avant l'ouverture de Gestion, le "crash" ne se produit pas.

Les conditions testées d'ouverture de Gestion ont été les suivantes:

1. Lancement d'Excel depuis le DOCK, puis ouverture de Gestion à partir du menu fichier, commande " ouvrir " : " crash "
2. Lancement d'Excel depuis le DOCK, puis ouverture de Gestion à partir de la liste des fichiers récents (menu fichier) : " crash "
3. Lancement d'Excel depuis le menu Pomme, en choisissant Gestion dans liste des éléments récents : pas de " crash".
4. Lancement d'Excel par double-clic sur l'icône de Gestion : pas de " crash".

Autre condition de test :

J'ai créé un classeur rigoureusement vide, ne comportant que les 27 feuilles avec les même noms de feuilles. J'ai effectué les mêmes essais et les résultats sont identiques.

Conditions de démarrage :

J'ai effectué les tests dans les conditions suivantes :

1. Le dossier de démarrage par défaut contient Modèle et Macros. Il n'y a pas d'autre dossier défini dans les Préférences Générales.
2. Le dossier de démarrage par défaut contient les alias des classeurs Modèle et Macros situé dans un autre dossier. Il n'y a pas d'autre dossier défini dans les Préférences rubrique " Général ".
3. Le dossier de démarrage par défaut est vide et le dossier secondaire contient les classeurs Modèle et Macros. Le dossier secondaire est défini dans les Préférences rubrique " Général ".

Précisions importantes :

Ce problème de crash ne se produit que pour une série de classeurs de même modèle, comportant 27 feuilles.

J'utilise le compte administrateur, et ce problème n'existe qu'avec ce compte.
Il n'existe pas sur un compte lambda utilisant les mêmes fichiers rendus accessibles par partage (Préférences Système, Partage de dossiers).


Configuration:

iMac Alu 2008, (2,66 GHz)
OS : Leopard 10.5.6 à jour
Office 2004 (version 11.5.4 (090302)

Vérification des autorisations : OK

 

[Aliboron]

Si on peut résumes, le plantage ne survient qu'au moment de l'ouverture par un classeur particulier des classeurs de macros lorsque ceux-ci sont déjà ouverts (puisqu'ils sont dans un dossier qui en lance l'ouverture en même temps que l'application. Et cela uniquement dans le compte utilisateur habituel.

Ton dossier "secondaire" (je suppose qu'il s'agit de celui qui est désigné dans "Autres dossier de démarrage"), où est-il situé ?

 

[da capo]

Autre piste de recherche : la confusion des "noms".

Une feuille du classeur a un nom interdit ou causant une exception dans le code d'une macro.

Une méthode peut-être d'éliminer une à une les feuilles d'un classeur jusqu'à obtenir un démarrage normal.

Là on en saura peut être un peu plus.


Ou chercher dans le code des macros si on n'a pas une occurence d'un terme égal ou correspondant à un nom de feuille dans un contexte inapproprié.

 

[iluro_64]

Si on peut résumes, le plantage ne survient qu'au moment de l'ouverture par un classeur particulier des classeurs de macros lorsque ceux-ci sont déjà ouverts (puisqu'ils sont dans un dossier qui en lance l'ouverture en même temps que l'application. Et cela uniquement dans le compte utilisateur habituel.

C'est tout à fait cela.

Ton dossier "secondaire" (je suppose qu'il s'agit de celui qui est désigné dans "Autres dossier de démarrage"), où est-il situé ?

Oui, c'est celui-là.
Il est situé ainsi : Maison (utilisateur)/Documents/Maison/Comptes/ICI

---------- Nouveau message ajouté à 18h15 ---------- Le message précédent a été envoyé à 18h06 ----------

Autre piste de recherche : la confusion des "noms".

Une feuille du classeur a un nom interdit ou causant une exception dans le code d'une macro.

Une méthode peut-être d'éliminer une à une les feuilles d'un classeur jusqu'à obtenir un démarrage normal.

Là on en saura peut être un peu plus.


Ou chercher dans le code des macros si on n'a pas une occurence d'un terme égal ou correspondant à un nom de feuille dans un contexte inapproprié.

Oui, j'ai pensé à cela. J'ai commencé à entreprendre des recherches.

Question que je pose alors, pourquoi n'avais-je pas ce problème avec Excel v.X

J'ai une question à poser après avoir fait l'essai suivant.

J'ai créé un nouvel modèle par défaut de classeur. Puis, j'ai créé un nouveau classeur à partir de ce nouvel modèle. Pour le moment, ce classeur est vide, et ne comporte que trois feuilles. Il ne pose pas de problème d'ouverture puisque, pour le moment, il n'a pas été utilisé la moindre macro. J'ai remarqué qu'à l'ouverture (mais peut-être est-ce normal) que la fenêtre posant la question d'activation et de désactivation des macros ne s'affichait pas. Et là est la question : cette fenêtre doit-elle s'afficher quoi qu'il arrive ?

 

[Aliboron]

Il est situé ainsi : Maison (utilisateur)/Documents/Maison/Comptes/ICI

Ah. Et alors, que se passe-t-il exactement lorsque tu ouvres le classeur "Gestion" dans une autre session ? Parce que, normalement, il n'a pas accès à ce classeur-ci, qui se trouve dans un autre compte utilisateur (contrairement à celui qui se trouve dans le dossier de démarrage, donc dans /Applications)... Pourquoi ne le mets-tu pas dans le dossier de démarrage, au fait (c'est l'emplacement par défaut du classeur "Macros personnelles") ?

Tout ça me fait penser qu'il y a une sorte de conflit au moment du lancement de ton classeur de macros. Même si je ne vois pas bien pourquoi. Tu peux toujours essayer de le recréer. En recopiant tout le contenu du module (des modules, s'il y en a plusieurs) dans un fichier en texte brut (par ex avec TextEdit) puis en supprimant le classeur de macros personnelles et en en recréant un dans le module duquel tu colles les macros précédemment copiées. Si c'est une corruption de macros, ça devrait permettre de résoudre le problème. Mais ce n'est qu'une hypothèse, facile à tester. Pas du tout une certitude pour le moment...

Question que je pose alors, pourquoi n'avais-je pas ce problème avec Excel v.X

Il est trop tôt pour le dire. Visiblement quelque chose ne se passe pas de la même façon, mais on ne sait pas encore bien quoi.

J'ai créé un nouvel modèle par défaut de classeur. Puis, j'ai créé un nouveau classeur à partir de ce nouvel modèle. Pour le moment, ce classeur est vide, et ne comporte que trois feuilles. Il ne pose pas de problème d'ouverture puisque, pour le moment, il n'a pas été utilisé la moindre macro. J'ai remarqué qu'à l'ouverture (mais peut-être est-ce normal) que la fenêtre posant la question d'activation et de désactivation des macros ne s'affichait pas. Et là est la question : cette fenêtre doit-elle s'afficher quoi qu'il arrive ?

Non. Cette alerte ne s'affiche que si deux conditions sont remplies :
1 - le classeur contient une macro (ou quelque chose d'assimilé mais passons sur ce point) :
2 - la case "Avertir avant d'ouvrir un classeur contenant des macros" est cochée dans l'onglet "Sécurité" des préférences.

Dans ton cas, il est donc logique que l'ouverture du classeur ne déclenche rien. C'est seulement lorsque tu y auras mis une commande macro que l'alerte se déclenchera. Même chose (je présume) avec le classeur "Gestion" si tu tiens la touche majuscule enfoncée pendant son lancement...

 

[iluro_64]

Ah. Et alors, que se passe-t-il exactement lorsque tu ouvres le classeur "Gestion" dans une autre session ? Parce que, normalement, il n'a pas accès à ce classeur-ci, qui se trouve dans un autre compte utilisateur (contrairement à celui qui se trouve dans le dossier de démarrage, donc dans /Applications)... Pourquoi ne le mets-tu pas dans le dossier de démarrage, au fait (c'est l'emplacement par défaut du classeur "Macros personnelles") ?

Attention : pour faire un test avec un utilisateur lamba, j'ai déclaré "partagé dans un premier temps les données.
L'arborescence est la suivante :Maison (utilisateur)/Documents/Maison/Comptes/ICI.
À l'emplacement ICI,

1. il y a le dossier dossier de démarrage nommé Macros personnelles qui comprend :
   1. le modèle de document que j'ai nommé Modèle pour la création d'un nouveau classeur afin de récupérer les styles définis au fil du temps
   2. un classeur qui n'est que la forme non modèle du précédent et qui sert à la "maintenance"
   3. le classeur que j'ai nommé Macros
2. Un semble de fichiers du même modèle que celui que j'ai nommé Gestion, qui sont au format Excel 97-2004, et qui ont tous le même problème. En toute rigueur, celui sur lequel je fais les essais est une copie de "Gestion 2009" que j'ai baptisé Gestion pour simplifier.

Pour les tests avec un utilisateur lambda, j'ai fait déclaré le partage de dossier au niveau Comptes dans un premier temps, et au niveau Documents dans un second temps. Dans les deux cas c'était normal puisque l'autre dossier d'ouverture était toujours visible.

D'une façon générale, que les éléments cités soit dans le dossier d'ouverture principal ou dans le dossier d'ouverture secondaire ne change rien au problème.

Tout ça me fait penser qu'il y a une sorte de conflit au moment du lancement de ton classeur de macros. Même si je ne vois pas bien pourquoi. Tu peux toujours essayer de le recréer. En recopiant tout le contenu du module (des modules, s'il y en a plusieurs) dans un fichier en texte brut (par ex avec TextEdit) puis en supprimant le classeur de macros personnelles et en en recréant un dans le module duquel tu colles les macros précédemment copiées. Si c'est une corruption de macros, ça devrait permettre de résoudre le problème. Mais ce n'est qu'une hypothèse, facile à tester. Pas du tout une certitude pour le moment...

Il est trop tôt pour le dire. Visiblement quelque chose ne se passe pas de la même façon, mais on ne sait pas encore bien quoi..

Si l'on examine les quatre conditions d'ouverture, deux sont avec crash, et deux sont sans crash. On peut même remarquer que les conditions vont 2 par 2.

J'avoue que cela me trouble.

1. Dans le cas du crash, Excel a été lancé, et les classeurs ouverts sont masqués et l'ouverture de Gestion se fait ensuite au moyen d'une commande partie d'Excel (ouverture, ou éléments récents dans Excel)
2. Dans le cas de non crash, le lancement d'Excel se fait comme conséquence de l'ordre d'ouverture d'un fichier, soit par double-clic, soit depuis la listes des éléments récents du système (menu Pomme), c'est dire au niveau du Finder (ou du système).

Non. Cette alerte ne s'affiche que si deux conditions sont remplies :
1 - le classeur contient une macro (ou quelque chose d'assimilé mais passons sur ce point) :
2 - la case "Avertir avant d'ouvrir un classeur contenant des macros" est cochée dans l'onglet "Sécurité" des préférences.

Dans ton cas, il est donc logique que l'ouverture du classeur ne déclenche rien. C'est seulement lorsque tu y auras mis une commande macro que l'alerte se déclenchera. Même chose (je présume) avec le classeur "Gestion" si tu tiens la touche majuscule enfoncée pendant son lancement...

OK. La case des préférences d'Excel est effectivement cochée.



Petit à petit, à l'aide d'un fichier nommé Test 1 (dont je conserve des copies à chaque stade), je recrée le fichier Gestion.
J'en suis au point au j'ai créé un fichier de même structure en partant du modèle Modèle, et peu à peu, j'ai ajouté les 27 feuilles en leur faisant porter les mêmes noms que dans le classeur Classeur. À ce stade, le classeur est vide, au nom de feuilles près. J'ai essayé quelques macros pour voir ce qu'il se passait.

1. Macros générales de colorisation de cellules sélectionnées. La fonction de ces macros est de donner une couleur de fond à une ou plusieurs cellules sélectionnées. Bien plus pratique en une commande clavier que toute autre possibilité de palette.
2. Macros spécifiques de classement des feuilles en fonction de l'utilisation du classeur : ordre 1, ordre 2, ordre 3.

L'exécution de ces macros ne perturbent pas le fonctionnement de l'ouverture du classeur Test 1.

La prochaine étape est de remplir peu à peu le classeur. Cela risque d'être long, car je crains que si je le fais par des copier-coller, je copie aussi la cause du dysfonctionnement.

J'ai aussi fait les essais suivants. À partir d'une copie du classeur Gestion, j'enlève peu à peu les éléments pour voir ce qu'il en est. J'ai déjà ôter les valeurs de type constantes. Mais rien n'y a fait. Je poursuis cette exploration qui est assez rapide, car je pense aussi à une corruption du classeur. Après, j'envisagerai la corruption des macros.

Autre piste de recherche : la confusion des "noms".

Globalement, je pense plutôt à une éventuelle corruption récente du classeur qui contient les macros. Je dis récente parce que je n'avais pas ce problème lorsque j'utilisai Excel v.X et qu'il est apparu récemment alors que j'utilisai Excel 2004. Je suppose qu'un conflit de nom aurait eu le même effet dans les deux versions.

Une feuille du classeur a un nom interdit ou causant une exception dans le code d'une macro.

Une méthode peut-être d'éliminer une à une les feuilles d'un classeur jusqu'à obtenir un démarrage normal.

Là on en saura peut être un peu plus.

Cela serait possible si en passant de v.X à 2004 un nouveau terme interdit serait arrivé, et qu'il exstait en v.X

Ou chercher dans le code des macros si on n'a pas une occurence d'un terme égal ou correspondant à un nom de feuille dans un contexte inapproprié.

Mais cela ne suppose-t-il pas que la macro en question "planterait" en cours d'exécution ? Or, quand le classeur Gestion a été ouvert à l'aide de la méthode appropriée, je n'ai pas eu de dysfonctionnement en cours d'exécution des principales macros utilisables par ce classeur.

Pourtant, il est vrai que le rapport de crash d'Excel semble parler d'exception. En voici l'en tête :

Process: Microsoft Excel 2004 [438]
Path: /Applications/Microsoft Office 2004/Microsoft Excel 2004
Identifier: com.microsoft.Excel
Version: 090302 (11.5.4)
Code Type: PPC (Translated)
Parent Process: launchd [73]

Date/Time: 2009-05-04 13:06:35.130 +0200
OS Version: Mac OS X 10.5.6 (9G55)
Report Version: 6

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000004
Crashed Thread: 0

 

[Aliboron]

Tes nouveaux tests semblent plutôt confirmer la corruption du classeur. Apparemment, lors de l'ouverture du classeur avec les deux classeurs invisibles déjà ouverts, il doit y avoir "quelque chose" qui tente une deuxième ouverture d'un de ces classeurs, ou qui fait un test causant le plantage. Pas évident de creuser plus loin comme ça...

Il n'est pas fondamentalement surprenant qu'une corruption apparaisse lors d'un changement de version, les bouts de codes concernés par une opération ou une autre étant éventuellement un peu différents selon les versions, cela peut "révéler" un problème qui restait sous-jacent jusque là. Récemment, on en a vu pas mal d'exemples lors du passage d'Office 2004 à Office 2008.

Et, en effet, le transfert par copier-coller est à éviter car il "transporte" aussi des éléments invisibles et la corruption peut tout à fait être conservée. Il est toutefois possible de neutraliser les données en passant par un format texte brut ou par une autre application non sensible (ou du moins pas sensible aux mêmes éléments, par ex OpenOffice.org). Ceci dit, dans un premier temps, un simple collage spécial > "Valeurs" peut mériter un essai lorsqu'on a de grandes séries de données.

 

[iluro_64]

Tes nouveaux tests semblent plutôt confirmer la corruption du classeur. Apparemment, lors de l'ouverture du classeur avec les deux classeurs invisibles déjà ouverts, il doit y avoir "quelque chose" qui tente une deuxième ouverture d'un de ces classeurs, ou qui fait un test causant le plantage. Pas évident de creuser plus loin comme ça...]

Il n'est pas fondamentalement surprenant qu'une corruption apparaisse lors d'un changement de version, les bouts de codes concernés par une opération ou une autre étant éventuellement un peu différents selon les versions, cela peut "révéler" un problème qui restait sous-jacent jusque là. Récemment, on en a vu pas mal d'exemples lors du passage d'Office 2004 à Office 2008.

Bien content de te l'entendre dire. Après les essais que tu verras plus bas, on est porté vers cette hypothèse. Pour simplifier : un classeur créé avec Excel 2004 ne crashe pas, tandis qu'un fichier créé avant 2004, disons v.X pour ceux qui nous occupent, crashe. Pourtant, j'ai des fichiers qui utilisent des macros du même classeur de macros, et qui datent aussi de v.X qui eux ne crashent pas.

Et, en effet, le transfert par copier-coller est à éviter car il "transporte" aussi des éléments invisibles et la corruption peut tout à fait être conservée. Il est toutefois possible de neutraliser les données en passant par un format texte brut ou par une autre application non sensible (ou du moins pas sensible aux mêmes éléments, par ex OpenOffice.org). Ceci dit, dans un premier temps, un simple collage spécial > "Valeurs" peut mériter un essai lorsqu'on a de grandes séries de données.

Cette remarque me donne l'idée suivante. Parmi les classeurs passés en Excel 2008, un avait perdu SA macro. Du coup, je l'ai repassé en Excel 2004, et il a récupéré sa macro sans broncher. Avant de me lancer dans le copier-coller qui risque de me demander plusieurs jours, je vais tenter la manip suivante : passer le classeur crasheur dans la moulinette 2004 -> 2008 -> 2004. Ce n'est pas long et ça ne coûte pas cher.

Voici les essais réalisés au cours de ces dernières heures.

Essais effectués pour déterminer si le problème est en relation avec des données du classeur, telles que liaisons externes, ou formules contenant des maisons externes.

Essai conduit à partir d'un classeur nommé "Gestion modèle 2009" dans lequel toutes les données saisies ont été effacées. Seuls subsistent des textes formant titre de rangées et de colonnes, toutes les étiquettes attribuées à des cellules individuelles ou à des groupes de cellules, visibles soit au niveau de chaque feuille, soit au niveau de toutes les feuilles, et toutes les formules.

1. Essai 1 : toutes les étiquettes visibles par toutes les feuilles ont été supprimées.
   
2. Essai 2 : toutes les étiquettes visibles au niveau de chaque feuille ont été supprimées (feuille après feuille).
   
3. Essai 3 : toutes les formules et les textes de titres ont été supprimées. Le classeur était alors réputé " vide "

Aucun de ces essais n'a apporté d'indice.


Essais effectués, comme cela a été suggéré, en essayant de déterminer si le problème est lié au nom à une "connexion interdite" entre une ou plusieurs feuilles du classeur avec le classeur contenant les macros.

1. En partant d'une copie du classeur " Gestion modèle 2009 " les feuilles ont été supprimées l'une après l'autre en partant de la dernière à la première. Cet essai n'a pas apporté d'indice.
   
2. En partant d'une copie du classeur " Gestion modèle 2009 ", la feuille restante de lésé précédent a été la seule supprimée. Cet essai n'a pas apporté d'indice.
   
3. Enfin, en partant d'une copie du classeur " Gestion modèle 2009 " dans lequel il ne reste que la première feuille, un feuille a été ajoutée, et la feuille restante a été supprimée. Cet essai n'a pas apporté d'indice.

Ces essais semblent indiquer que le problème se situe non pas au niveau des données du classeur, mais au niveau de données mémorisées par Excel et inaccessibles à l'utilisateur, puisqu'un classeur vidée de sa substance continue de "crasher".

Essais essayant de mettre en évidence que ce problème est peut-être lié à la façon dont le fichier a été utilisé par des macros.

1. Création d'un classeur "vide" à partir du classeur Modèle.
2. Structuration du classeur sur le modèle du Classeur modèle 2009, avec 27 feuilles portant les mêmes noms.
3. Exécution de trois macros spécifiques permettant de réordonner l'ordre des feuilles.
4. Exécution de trois macros générales, non liées au modèle de classeur, permettant de coloriser une ou plusieurs cellules sélectionnées.

À aucune de ces étapes, le classeur n'a "subit de dommage", et il ne crashe pas.

 

[iluro_64]

Essais avec les classeurs objets du problème de crash à l’ouverture.

Ces essais ont pour objet de déterminer si les classeurs en question sont détenteurs de "code résiduel" lié à l’exécution de macros. Ce "code résiduel" aurait comme conséquence de perturber l’exécution de l’ouverture des classeurs en question dans les conditions observées précisément.

Rappel. La commande d’ouverture effectuée depuis Excel 2004 soit à partir de la commande "Ouvrir", soit à partir de la liste des éléments récents entraîne l’apparition de la fenêtre de pilotage de l’activation ou de la désactivation des macros (case cochée dans les Préférences Générales d’Excel). Que la réponse soit activation ou désactivation, le processus conduit à un "crash".
Il faut noter que ce crash ne se produit pas si un classeur (sans problème) a été préalablement ouvert à condition qu’il ne soit pas masqué. Ainsi, si le lancement d’Excel 2004 entraîne l’ouverture de classeurs masqués, le crash se produit. En revanche il ne se produit pas si le lancement entraîne l’ouverture de classeurs dont au moins un n’est pas masqué. De la même façon, il ne se produit pas si après l’ouverture de classeurs masqués, l’un d’eux est affiché.

Principe des essais.

1. Excel 2008 ne reconnaissant plus les macros, l’idée est d’ouvrir des classeurs "crashant" à l’aide d’Excel 2008 (en choisissant l’option "Supprimer les macros") et de les enregistrer au format Excel 2008.xlsx. Cette opération, si l’hypothèse émise est exacte (code résiduel) doit nettoyer les classeurs en question de toute référence aux macros.
2. Ensuite, toujours avec Excel 2008, les classeurs obtenus et de format. xlsx sont ouverts puis enregistrés au format Excel 97-2004.xls. Cette opération, si l’hypothèse émise est exacte (code résiduel) doit produire des classeurs exempts de toute référence aux macros puisqu’ils découlent de classeurs n’en ayant pas.
3. Enfin, ces classeurs sont ouverts par Excel 2004 dans les conditions de "crash".

Essais effectués

Première série d’essais effectués avec une série de fichiers dont le nom de base est "Gestion Modèle 2009" ayant servi à constater l’incidence de la disparition des progressives des données, des étiquettes et des formules, et aboutissant à un classeur final vidé.

1. Avec Excel 2008 : ouverture de Gestion Modèle 2009", et création d’un classeur "Gestion Modèle 2009-EX2008.xlsx".
2. Avec Excel 2004 : ouverture de Gestion Modèle 2009-EX2008.xlsx", et création d’un classeur "Gestion Modèle 2009-EX2004.xls", et ouverture de "Gestion Modèle 2009-EX2004.xls", dans les conditions de crash.
3. Avec Excel 2004 : exécution de trois macros spécifiques permettant de réordonner l’ordre des feuilles, puis fermeture du classeur avec enregistrement des modifications.
4. Avec Excel 2004 : ouverture de "Gestion Modèle 2009-EX2004.xls", dans les conditions de crash.

Ces essais ont été conduits avec 5 fichiers, et le résultat a été concluant, les 5 classeurs se sont ouverts sans crash. Je précise, afin qu’il n’y ait pas d’ambiguïté, qu’Excel 2004 a été lancé puis quitté à chaque classeur examiné.


J’ai enfin reconduit la même procédure avec une copie d’un classeur "réel", et le résultat a été convaincant. Le fichier qui "crashait", ne "crashe" plus, et les macros spécifiques de ce type de classeur sont exécutées avec succès.

Je publie ces résultats, car je pense être au bout de la recherche, et, sinon, tenir une solution qui corrige le problème. De toute façon, un certain nombre de classeurs doivent être ainsi "nettoyés", et je signalerai tout problème s'il est en relation avec ce thème.


En conclusion, et sauf erreur d'analyse, le problème apparaît être la présence d'un code résiduel inscrit dans les classeurs perturbés, qui perturbe l'exécution des classeurs en question lors de l'ouverture dans des conditions très précises.
Les classeurs en quelque sorte pollués peuvent être dépollués en leur faisant subir une conversion d'Excel 2004 à Excel 2008 (format xlsx) et d'Excel 2008 à Excel 2004 (format xls).

 

[Aliboron]

En conclusion, et sauf erreur d'analyse, le problème apparaît être la présence d'un code résiduel inscrit dans les classeurs perturbés, qui perturbe l'exécution des classeurs en question lors de l'ouverture dans des conditions très précises.
Les classeurs en quelque sorte pollués peuvent être dépollués en leur faisant subir une conversion d'Excel 2004 à Excel 2008 (format xlsx) et d'Excel 2008 à Excel 2004 (format xls).

Oui. Mais bon, il est vrai que dans le cas présent le passage par le format OpenXML a visiblement résolu le problème de corruption, on ne peut pas pour autant considérer que c'est une méthode transposable à d'autres cas. On a eu aussi des exemples (un peu comparables au tien, en quelque sorte) pour lesquels le passage à Excel 2008 a révélé une corruption qui n'apparaissait pas avec Excel 2004.

En gros, on peut dire que tous les coups sont permis lorsqu'un classeur fonctionne mal. L'idéal étant de pouvoir conserver le classeur au plus proche de son état habituel, ce qui a été le cas ici, mais sinon il faut aller plus loin, le plus fastidieux étant lorsqu'il faut tout refaire de zéro. Dans les intermédiaires, ne pas oublier de tenter avec les applications compatibles, comme par exemple OpenOffice.org ou Numbers...

En tout cas, on ne peut que te féliciter pour la précision de ta description des tests car cela permet de bien suivre les étapes (on peut supposer que ça t'a aidé du même coup à cerner le problème).

 

[iluro_64]

Oui. Mais bon, il est vrai que dans le cas présent le passage par le format OpenXML a visiblement résolu le problème de corruption, on ne peut pas pour autant considérer que c'est une méthode transposable à d'autres cas. On a eu aussi des exemples (un peu comparables au tien, en quelque sorte) pour lesquels le passage à Excel 2008 a révélé une corruption qui n'apparaissait pas avec Excel 2004.

En gros, on peut dire que tous les coups sont permis lorsqu'un classeur fonctionne mal. L'idéal étant de pouvoir conserver le classeur au plus proche de son état habituel, ce qui a été le cas ici, mais sinon il faut aller plus loin, le plus fastidieux étant lorsqu'il faut tout refaire de zéro. Dans les intermédiaires, ne pas oublier de tenter avec les applications compatibles, comme par exemple OpenOffice.org ou Numbers...

En tout cas, on ne peut que te féliciter pour la précision de ta description des tests car cela permet de bien suivre les étapes (on peut supposer que ça t'a aidé du même coup à cerner le problème).

Je me suis aussi demandé pour quelle raison certains classeurs étaient corrompus, et pas d'autres. Bien que je n'ai encore totalement achevé les investigations, il semble qu'il y a quatre ou cinq ans, la structure de base des classeurs corrompus ait subi une adaptation à une situation qui n'existait pas antérieurement (nouvelles données à prendre en compte, et adaptation consécutive de macros). Avant cette adaptation, pas de problème (pour le moment). À partir de cette adaptation, problème. Comme chaque classeur d'une année donnée sert de modèle (aux données comptables près) pour l'année suivante, je pense que c'est ainsi que le problème s'est posé. Pour une raison que j'ignore, le classeur de l'année en cours a été corrompu lors de cette adaptation, et s'est ainsi propagé sans que ce soit dommageable. Un peu comme un virus est propagé par des porteurs sains.

C'est en passant définitivement d'Office X à Office 2004 (ou à 2008 pour ceux qui n'ont pas de macros), que je suis tombé sur le problème tout à fait par hasard. En effet, compte tenu du fait que Excel 2008 est l'application par défaut au lancement par double-clic, depuis la cohabitation d'Excel 2004 et d'Excel 2008, au lieu de lancer cette sorte de classeurs par un double-clic je suis passé par Excel 2004. En effet, pour une raison que j'ignore, et que je n'ai pas exploré en détail, les classeurs 97-2004, en dépit de la spécification d'ouverture par Excel 2004, arrivent à perdre cette spécification, et sont ouverts par Excel 2008. Mias, comme les choses sont plus claires maintenant, je vais jeter un coup d'œil sur ce problème.

 

[Aliboron]

.../... pour une raison que j'ignore, et que je n'ai pas exploré en détail, les classeurs 97-2004, en dépit de la spécification d'ouverture par Excel 2004, arrivent à perdre cette spécification, et sont ouverts par Excel 2008.

C'est tout à fait normal. C'est toujours la version la plus récente d'une application qui est retenue pour l'ouverture par le système. Sauf si une autre version est déjà lancée, si je me souviens bien, en quel cas le fichier est envoyé directement à celle-là.

Pour la corruption, ne te prends pas trop la tête. Cela arrive toujours, surtout avec les documents qui ont une histoire longue. C'est un peu comme les mutations génétiques spontanées. Il y a tout le temps des petites erreurs qui se glissent dans les fichiers. Le plus souvent c'est sans conséquence mais, parfois, cela provoque des dysfonctionnements visibles. Et c'est bien entendu transmis dans toutes les copies ultérieures du document.

C'est exactement la même chose avec les fameux fichiers de préférences dans Mac OS X qui sont, eux aussi, très fréquemment modifiés et réenregistrés. De temps en temps, la corruption qui en résulte provoque des altérations du fonctionnement et il faut remettre à zéro (la fameuse étape de "suppression des préférences"). Et c'est aussi pour les mêmes raisons que les fichiers de type base de données doivent faire l'objet de maintenance périodiquement.

 

[iluro_64]

C'est tout à fait normal. C'est toujours la version la plus récente d'une application qui est retenue pour l'ouverture par le système. Sauf si une autre version est déjà lancée, si je me souviens bien, en quel cas le fichier est envoyé directement à celle-là.

Pour la corruption, ne te prends pas trop la tête. Cela arrive toujours, surtout avec les documents qui ont une histoire longue. C'est un peu comme les mutations génétiques spontanées. Il y a tout le temps des petites erreurs qui se glissent dans les fichiers. Le plus souvent c'est sans conséquence mais, parfois, cela provoque des dysfonctionnements visibles. Et c'est bien entendu transmis dans toutes les copies ultérieures du document.

C'est exactement la même chose avec les fameux fichiers de préférences dans Mac OS X qui sont, eux aussi, très fréquemment modifiés et réenregistrés. De temps en temps, la corruption qui en résulte provoque des altérations du fonctionnement et il faut remettre à zéro (la fameuse étape de "suppression des préférences"). Et c'est aussi pour les mêmes raisons que les fichiers de type base de données doivent faire l'objet de maintenance périodiquement.

J'ai pratiquement terminé, encore une dizaine de "vieux" classeurs bien identifiés à "dépolluer" (dans la mesure où ils le seraient). Un petit coup de moulinette par XML, ça ne leur fera pas de mal.

Quant au lancement par double-clic, j'ai noté que ça marche toujours si l'application recherchée est lancée, ou bien si le double-clic se fait immédiatement après avoir spécifié l'application à la place de celle qui "monte" par défaut. Mais, ensuite, après fermeture, un nouveau lancement lance l'application par défaut. C'est embêtant. Il faudrait une possibilité de réglage, pour résoudre ce problème lorsque deux applications pouvant ouvrir les mêmes fichiers cohabitent.