Excel : changement de la police d'affichage

[iluro_64]

En fait ce problème plus énervant qu'important existait aussi du temps d'Office 365, toujours là avec la version Microsoft 365.

J'ai une application qui compte une trentaine de feuilles de calcul. Chaque jour au moins 3 d'entre elles sont mises à contribution.
Toutes ces feuilles ont pour police Helvetica 12, et la police par défaut définie dans les Préférences/Général est aussi Helvetica 12.

Lorsque j'ouvre ce classeur, j'ai souvent ce phénomène : les feuilles affichées n'ont plus leur apparence de base, parce que la police des feuilles est devenue Verdana 10. Ce changement d'apparence est "chaotique", c'est-à-dire imprévisible, aléatoire, pas du tout reproductible, et tout à fait énervant. Il se produit ou ne se produit pas sur tout ou partie des feuilles du classeur, que les feuilles soient sélectionnées ou non à l'ouverture du classeur. Je ne saurai être affirmatif pour dire que j'ai constaté ce phénomène sur toutes les feuilles.

Je me demande, s'il n'y a pas un fichier quelque part que l'une des mises à jour d'Office/Microsoft 365 a oublié d'éliminer et qui est sollicité alors qu'il devrait pas l'être. Je pense bien sûr à un fichier de "style" ou la police par défaut serait Verdana 10.

Merci par avance à ceux qui peuvent me suggérer quelque chose.

 

[RubenF]

Hello, est-ce que le fichier est bien en xslx ?

J'ai ce défaut avec OneDrive, toute mon équipe bosse sur PC et moi sur Mac j'ai souvent ce soucis. je vérifie bien que mes documents sont en docx ou xslx.

Les documents qui passent en verdana 10 doivent être repassé en xls.

A checker.

 

[Aliboron]

D'après ta description, je pense que cela peut être une corruption légère du classeur. Assez classique avec les fichiers qui ont un long historique de modifications, changement, ajouts, etc. (ce qui semble être le cas). Le meilleur moyen de "nettoyage" consiste à ouvrir une copie du classeur avec LibreOffice puis à l'enregistrer (toujours au format .xlsx, bien entendu). La double conversion que cette manip implique donne habituellement de bons résultats, sans trop de dégâts en matière de mise en forme. Et ça ne coûte rien...

NB : Verdana 10 était la police par défaut d'Excel 2011. Ne serait-ce pas la version avec laquelle ce classeur a été créé ?

Les documents qui passent en verdana 10 doivent être repassé en xls

Il est totalement exclu qu'un classeur "repasse" spontanément en .xls (et encore moins certaines feuilles d'un classeur, bien sûr).

 

[iluro_64]

Merci pour vos réponses qui m'ont incité à faire quelques manip.
Pour clore cette hypothèse, aucun des classeurs de cette collection que je manipule chaque jour n'a le suffixe .xls.
Tous portent le suffixe .xlsx

J'ai vérifié chaque classeur dont je doit dire qu'ils ont en commun 26 feuilles liées entre elles par le biais de noms de cellules ou de groupes de cellules (en colonne). La liaison entre les classeurs s'effectuent à l'aide d'un classeur intermédiaire et d'un jeu de quelques macros. 24 de ces feuilles soit associées par deux et représentent un élément d'un premier groupe de 12, nommons le A, et d'un second groupe de 12, nommons le B. Parmi les macros utilisées quelques-unes traitent les feuilles des groupes A et B séparément pour de simple raison de confort (le mien).

J'ai donc vérifié les polices des classeurs allant de 1979 à 2020.
Les classeurs allant de 1979 à 1987 ont tous la police Geneva 9 (souvenir de mac avec de petits écrans ?).
À partir de 1988 ils étaient tous avec la police Helvetica 12. Mais pendant l'ouverture (je les ai ouvert 5 par 5 ou 10 par 10), j'ai vu clairement la police se modifier en Verdana 10. Cela a été particulièrement bien visualisé avec le classeur 2019. La dernière fois que j'ai ouvert ce classeur a été le 19/12/2019 (ouverture selon MS) et la dernière modification date du 19/03/2020 (selon MS). Je peux certifier grâce à Time Machine, que ce fichier était entièrement en police Helvetica ce jour-là. Mais, lorsque je l'ai ouvert tout à l' heure, le défaut est apparu sur une partie des feuilles, celles d'un des deux groupes A et B.

Quant au classeur 2020 sur lequel j'ai découvert cette bizarrerie, en affinant les recherches, j'ai constaté que les feuilles que je n'avais pas encore utilisées étaient "contaminées". Par contre toutes les feuilles que j'avais corrigées sont restées intactes en Helvetica 12.

Je dois apporter une petite précision. Chacun de ces classeurs a été créé avec le classeur de l'année précédente. Lorsqu'il y a eu quelques modifications de structures, elles ont été répercutées uniquement si c'était nécessaire. Pour simplifier, nous diront que pour chaque feuille le nombre de colonnes n'a pas changé au cours du temps. Seul le nombre de ligne a pu changer soit par ajout, soit par suppression. L'utilisation de noms a grandement facilité cette souplesse.

Il me reste une vérification à faire dans les macros. Comme j'ai remarqué qu'il arrivait que quelques feuilles d'un classeur atteint appartenait soit au groupe A soit au groupe B, il faut faut que je regarde si l'une des macros d'un des groupes n'est pas tout à fait la même pour l'autre groupe. Si cela existe, cela n'explique pas pourquoi la police Verdana a remplacé la police d'origine Helvetica, ni pourquoi lorsque les feuilles atteintes sont corrigées elles ne changent pas.

 

[Aliboron]

Et alors, le nettoyage de corruption par LibreOffice, qu'est-ce que ça donne ?

 

[baron]

Tu crois que les macros résisteront ? Ça a l'air d'être un sacré édifice de fichiers…

 

[iluro_64]

Et alors, le nettoyage de corruption par LibreOffice, qu'est-ce que ça donne ?

Avant de passer par cette étape ultime (Libre Office n'est pas installé sur mon iMac) j'ai commencé par vérifier qu'aucune des macros que j'utilisai ne contenait une instruction modifiant la police. Dans la foulée, j'en ai fait une pour rétablir Helvetica 12, ce qui m'a fait gagner un peu de temps, et de contrôler que sur tous les classeurs incriminés la police Verdana 10 ne revenait pas à chaque nouvelle ouverture. J'ai épargné un seul classeur pour en disposer en cas de besoin, avec Libre Office par exemple.
Il semble que ce remède soit efficace, que la "scorie" qui permettait cette bizarrerie d'être éliminée.

Tu crois que les macros résisteront ? Ça a l'air d'être un sacré édifice de fichiers…

Ben non ! Il n'y a qu'un classeur nouveau chaque année. L'essentiel se passe dans le classeur avec ses 27 à 30 feuilles selon les circonstances.

Il m'est arrivé d'avoir quelques soucis en passant d'Excel 2011 au suivant. J'avais posté cela et Aliboron, notre grand expert, m'avait signalé que la syntaxe ds chemins de fichiers avait changé. J'ai eu quelques gags par-ci par-là mais j'ai toujours réussi à m'en sortir soit à partir de l'aide du forum, soit seul après débat.
Concernant les classeurs de l'appli concernée, il n'y a rien de mystérieux et de compliqué. Il s'agit de ce que j'ai développé pour ma compatibilité personnelle. J'ai donc une feuille centrale représentant un budget annuel prévisionnel, deux feuilles par mois (un pour les comptes bancaires et un pour les opérations quotidiennes - on arrive ainsi à 25) une feuille où je place les opérations des relevés bancaires extraits du site de la banque, qui me permet de faire la corrélation entre les prévisions et les opérations effectuées. J'ai aussi une feuille pour les assurances maladie et mutuelle pour les dépenses de santé. Nous voilà avec 27 feuilles. Il y a parfois deux feuilles temporaires pour les vacances.

En fait, EXCEL s'accommode très bien de genre d'application pour peu qu'on n'ait pas peur de mettre les mains dans le cambouis. Il faut dire aussi que VBA n'est pas d'un accès très commode lorsqu'on ne l'utilise, comme moi, que très occasionnellement.

En conclusion, il ne me reste plus qu'à installer Libre Office et à voir ce qu'il en est.

 

[Aliboron]

Le passage par LibreOffice n'a rien d'ultime, c'est même d'une grande banalité. Et un classique dans le traitement de la corruption de classeurs (j'ai eu l'occasion d'en sauver plus d'un, même dans des environnements Windows où les versions d'Excel sont pourtant équipés de convertisseurs plus puissants que ceux des versions pour Mac).

Les macros peuvent éventuellement passer, mais ce n'est pas tellement utile. Mieux vaut recopier le code sur une page TextEdit et le recoller après traitement dans un module vierge. Comme ça, c'est nettoyé aussi (il ne faut pas croire, la corruption, ça peut aussi toucher les modules VBA).

Tant mieux si tu arrives à résoudre le problème à l'aide d'une macro à l'ouverture. On peut toutefois craindre que ça alourdisse inutilement le classeur (et que ça rajoute des risques de corruption, évidemment). Mais ce genre de "petites alertes" n'est pas à prendre trop à la légère, tu risques un jour d'avoir un blocage complet du classeur.

 

[iluro_64]

Le passage par LibreOffice n'a rien d'ultime, c'est même d'une grande banalité. Et un classique dans le traitement de la corruption de classeurs (j'ai eu l'occasion d'en sauver plus d'un, même dans des environnements Windows où les versions d'Excel sont pourtant équipés de convertisseurs plus puissants que ceux des versions pour Mac).

Les macros peuvent éventuellement passer, mais ce n'est pas tellement utile. Mieux vaut recopier le code sur une page TextEdit et le recoller après traitement dans un module vierge. Comme ça, c'est nettoyé aussi (il ne faut pas croire, la corruption, ça peut aussi toucher les modules VBA).

Tant mieux si tu arrives à résoudre le problème à l'aide d'une macro à l'ouverture. On peut toutefois craindre que ça alourdisse inutilement le classeur (et que ça rajoute des risques de corruption, évidemment). Mais ce genre de "petites alertes" n'est pas à prendre trop à la légère, tu risques un jour d'avoir un blocage complet du classeur.

La corruption des modules VBA, ça me connait. J'en ai eu une quand je faisais mes manip cet après-midi.

En ce qui concerne les classeurs, j'ai dû mal m'exprimer. Je n'ai pas de macro à l'ouverture pour ce problème. J'ai simplement fait une petite macro qui a pour seul rôle de définir en une seule commande que toutes cellules de toutes les feuilles du classeur devaient être Helvetica 12. J'ai utilisé cette petite macro comme "remède" avec tous les classeurs "corrompus". Comme, ensuite, j'ai ouvert tous les classeurs sans que la police Verdana réapparaisse, et que j'ai répété cette action plusieurs fois, j'en ai déduit que la "scorie" avait été nettoyée partout où elle existait.

C'était assez "stressant" de voir s'ouvrir un paquet de classeur s'ouvrir, voir les rubans avec Helvetica 12 remplacé par Verdana 10 dans la seconde suivante.

Merci pour ton aide toujours précieuse, et à ceux qui se sont intéressé au problème

 

[iluro_64]

Je réactive le débat, car j'ai du nouveau.

Le phénomène que j'ai décrit est réapparu mais avec deux nuances qui ne m'ont pas échappé. La première nuance, est que le phénomène n'est plus observable comme je le voyais, pratiquement en temps réel à l'activation d'une feuille : remplacement de Helvetica 12 par Verdana 10. Je ne sais plus lorsque le remplacement se fait. La seconde nuance est que j'ai pu me rendre compte compte qu'il se produisait car la différence de taille de la police était évidente. En tout cas je n'ai pas pu l'observer en temps réel. Je me suis aussi rendu compte qu'il n'affectait pas toutes les feuilles, mais seulement les 12 feuilles de même usage ou fonction, et un autre feuille qui n'est présente qu'accessoirement.

Depuis la dernière fois, j'avais chargé LibreOffice pais pour une autre raison.
J'ai alors ouvert un classeur, celui que j'utilise en ce moment, avec LibreOffice. Toutes les feuilles qui avaient été corrigées en Helvetica 12 ont été modifiées en Arial 12 pendant l'ouverture. Je me suis dit que les choses ne s'arrangeaient pas. J'ai modifié ensuite les préférences de LibreOffice de façon à ce que la police par défaut ne soit plus Arial 12 mais Helvetica 12. Et j'ai corrigé toutes les feuilles du classeur en Helvetica 12. J'ai enregistré le classeur sous un autre nom, l'ai fermé, puis réouvert, et toutes les feuilles étaient bien en Helvetica 12.
Dans l'instant suivant, j'ai ouvert le nouveau classeur avec Excel, et n'ai pas constaté de changement. Du coup, je me demandai si l'hypothèse émise par Aliboron n'était pas la bonne. C'est-à-dire, en ré-enregistrant le classeur Excel, LibreOffice le fait à sa manière, mais de façon compatible, et ne tient pas compte d'une "scorie" (c'est-à-dire ne l'enregistre pas) qu'Excel utilise à sa façon.

Ce n'est qu'aujourd'hui que j'ai pu "maîtriser" LibreOffice. Après l'avoir téléchargé, et installé le module langue, pour une raison que j'ignore, il ne voulait pas ouvrir les classeurs Excel en provenance d'Office 365 (explicitement exprimé). J'ai alors ré-enregistré un classeur au format .xls qui a été ouvert sans problème. Cela se passait avant-hier. Depuis, l'iMac a été plusieurs fois mis hors tension et sous tension. Lorsque j'ai repris les recherches hier, LibreOffice n'a pas rechigné à ouvrir mon classeur témoin au format .xlsx. C'est alors que j'ai pu avancer, et faire de compte rendu.

 

[iluro_64]

Je réactive cette discussion car j'ai trouvé une cause très vraisemblable de ce problème.
Tout à fait fait par hasard, et pour une autre raison, j'ai "coupé" les liens externes entre ce classeur et un classeur comprenant des données d'autres classeurs. On peut appeler cela un classeur de report. Du coup, le problème n'est plus reproduit.
J'ai pris le taureau par les cornes et j'ai refait un classeur identique, en récréant tout à la main, en prenant bien soin de ne pas coller de données du premier dans le second. Les deux classeurs sont comme deux clones. En utilisant une macro particulière qui fait appel au classeur de report, si je coupe les liaisons externes, le problème n'apparait pas. Si je rétablis les liaisons externes (une seule suffit) le problème agit sur le classeur basique, mais pas sur classeur cloné à la main.

Je suppose donc qu'un mécanisme dans Excel 365 agit sur la mise à jour de données de style lorsqu'une feuille active du classeur de base contient des informations qui sont des ascendants. Comme le classeur cloné à la main est tout récent, quelques jours, il ne contient pas de données d'ascendants. Il ne faut donc plus que j'utilise les données du classeur de report, et que je mette en place une autre solution qui assure la même fonction. C'est une partie de mes occupations actuelles. Cela m'oblige à créer quelques macro nouvelles sur lesquelles je peine un peu.

 

[iluro_64]

Je crois que je suis arrivé au bout du problème. Ouf ! Cette fois-ci ce n'est plus du hasard, mais un aboutissement de raisonnement.

Ayant observé que le clone n'était pas affecté, et que le père du clone restait affecté qu'il y ait ou non liaison(s) avec un ou d'autres classeurs, j'ai coupé les liaisons avec l'extérieur "du père" de façon à être certain que le problème était dû à une cause interne. Ensuite, j'ai fait tourner la macro à partir de laquelle le problème se produisait, en mettant un point d'arrêt à un endroit précis, avant l'arrêt de l'instruction suivante : Selection.Style = StyleMonnaie

Dans la macro, cette instruction a pour rôle de rétablir un style selon que les données adéquates du contenu du classeur sont affichées soit en Franc soit en euro, selon la date du classeur. Le nom du style se trouve dans la variable StyleMonnaie, chargée au moment utile soit à partir d'une constante contenant le nom StyleEuro, soit à partir d'une autre constante contenant le nom StyleFranc. Au moment où la macro a été écrite, dans les styles de données, on disposait de "Monétaire [2]€" et de "Monétaire [2]". Jusque-là, rien à dire sauf que la définition de ces styles, aujourd'hui, n'a pas le même sens qu'alors. Lorsque l'exécution s'est arrêtée avant l'instruction citée, la variable StyleMonnaie contenait bien "Monétaire [2]€". Avec le débogueur j'ai exécuté l'instruction, et j'ai vu la police Verdana 10 remplacer la police Helvetica 12. À l'aide des commandes d'Excel, j'ai examiné la définition du style Monétaire, où la police était devenu Verdana 10. Comme le but de l'instruction est avant tout d'avoir un affichage correct, j'ai remplacé Selection.Style = StyleMonnaie par Selection.NumberFormat = StyleMonnaie où la variable StyleMonnaie contient soit "#,##0.00"" €"";[Red]-#,##0.00"" €""", soit "#,##0.00"" F"";[Red]-#,##0.00"" F""".

Depuis, l'exécution est correcte. Le mécanisme interne à Excel qui, sans doute, cherche la définition du style, n'est plus sollicité, que le classeur soit relié ou non à d'autres classeurs.

Ce problème m'aura causé pas mal d'effervescence intellectuelle

 

[iluro_64]

Merci à ceux qui m'ont envoyé leurs encouragements.

J'ai une petite question à poser à ceux qui connaisse bien VBA.
Quelle instruction VBA permet-elle de récupérer le "contour" d'un tableau continu, si toutefois cela existe ?
À défaut peut-on récupérer l'emplacement d'un cellule, par exemple, celle d'un "coin" de tableau dont la première cellule est $A$1.

Grand merci à ceux qui m'apporteront une réponse, tant négative que positive.

 

[Aliboron]

Que veux-tu faire exactement ? Qu’entends-tu précisément par "tableau" ? Et par "récupérer" le contour ?

 

[baron]

Pour ce que j'en comprends, il s'agirait de déterminer quelles sont les coordonnées d'une plage de cellules entourée d'une bordure continue…?

 

[Aliboron]

Si (spéculation) tu cherches à connaître l’adresse de la cellule en haut à droite d’une plage continue (c’est à dire sans cellules vides), tu peux l’obtenir avec une instruction du type
X = Range("D6").End(xlToRight).End(xlUp).Address
en partant du principe que la cellule D6 est une cellule quelconque à l’intérieur de la plage.

Mais, comme vu, ce n’est qu’une des interprétations possibles de ta description.

 

[iluro_64]

Je te remercie. J'ai compris le principe.
En pratique, il s'agit de trouver la dernière cellule d'un tableau, en bas et à droite (ou à gauche, peu importe), la première étant la cellule "A1".

Je dois donc pouvoir écrire :
X=Range("A1").End(xlToLeft).End(xlDown).Address
Ainsi, je peux extraire de X le numéro de la dernière ligne du tableau, sachant que j'ai obtenu l'adresse de la dernière cellule non vide de la colonne "A".

L'idée de base est d'obtenir la taille utile du tableau pour éviter des traitements en boucle sur un tableau de 1000 lignes, par exemple, alors qu'il n'en a que 300.

 

[Aliboron]

Oui, enfin, ça mérite quelques ajustements, et quelques éclaircissements. Tu n'as toujours pas précisé ce que tu entends par "tableau". J'ai l'impression qu'il faut comprendre "plage" (c'est à dire un ensemble de cellules). Est-ce bien cela ?

Pour ce qui est de ta formule, si tu pars de A1, pas besoin de demander un décalage à gauche. La colonne étant déjà connue, tu peux donc écrire :

X=Range("A1").End(xlDown).Address​

Voire même, s'agissant de connaître la ligne :

X=Range("A1").End(xlDown).Row​

Habituellement, pour plus de rigueur (et résoudre l'éventuel problème des cellules vides) on part plutôt du bas de la feuille. Donc :

X = Range("A1048576").End(xlUp).Row​

Si, par contre, tu as des données en dessous de ton "tableau" (par ex. des commentaires) et que tu ne veux pas les prendre en compte, tu peux utiliser la propriété CurrentRegion :

X = Range("A1").CurrentRegion.Rows.Count​

Voir aussi Activesheet.UsedRange, dans un genre voisin, pour avoir la totalité de la plage utilisée sur une feuille (cellules vides incluses)

En bref, on a pas mal de possibilités, en fonction du contexte et de ce qu'on veut obtenir...

 

[iluro_64]

Oui, enfin, ça mérite quelques ajustements, et quelques éclaircissements. Tu n'as toujours pas précisé ce que tu entends par "tableau". J'ai l'impression qu'il faut comprendre "plage" (c'est à dire un ensemble de cellules). Est-ce bien cela ?

Pour ce qui est de ta formule, si tu pars de A1, pas besoin de demander un décalage à gauche. La colonne étant déjà connue, tu peux donc écrire :

X=Range("A1").End(xlDown).Address​

Voire même, s'agissant de connaître la ligne :

X=Range("A1").End(xlDown).Row​

Habituellement, pour plus de rigueur (et résoudre l'éventuel problème des cellules vides) on part plutôt du bas de la feuille. Donc :

X = Range("A1048576").End(xlUp).Row​

Si, par contre, tu as des données en dessous de ton "tableau" (par ex. des commentaires) et que tu ne veux pas les prendre en compte, tu peux utiliser la propriété CurrentRegion :

X = Range("A1").CurrentRegion.Rows.Count​

Voir aussi Activesheet.UsedRange, dans un genre voisin, pour avoir la totalité de la plage utilisée sur une feuille (cellules vides incluses)

En bref, on a pas mal de possibilités, en fonction du contexte et de ce qu'on veut obtenir...

Merci pour ces précisions.

Tu as bien compris le sens de "tableau". J'utilise tableau plutôt que plage. Sans doute cela vient-il de l'utilisation quotidienne d'Excel et FileMarker, ce dernier ayant une option de visualisation dite "tableau". C'est bien un ensemble de cellules de forme rectangulaire. Plusieurs tableaux peuvent cohabiter sur une même feuille. Lorsque cela arrive, je m'arrange pour qu'ils n'aient pas de cellules partagées. J'ai aussi hérité d'une habitude venant du temps ou je faisais du développement en Fortran ou en Pascal, j'apprécie Excel pour sa capacité utiliser des noms plutôt que des adresses "physiques". Mais je n'attribue pas généralement de nom me permettant de connaître facilement la fin d'un tableau.

Comme j'ai pas mal d'applications sur FileMaker qui ont été transposées d'Excel, et que je développe plus facilement sur FileMaker que sur Excel, j'utilise des termes qui peuvent être commun aux deux.

Encore merci, et à un de ces jours.