Excel 2016 et les alias

[iluro_64]

Compte tenu de l'obsolescence annoncée d'OFFICE 11, je m'apprête à passer à OFFICE 16, dont je n'utilise qu'EXCEL et, occasionnellement, WORD 16.

J'ai de gros problèmes avec EXCEL 11.

L'ouverture de classeur(s) au démarrage ne fonctionne plus si le nom de classeur est donné via un " alias ". Un message indique alors :
Le format ou l'extension du fichier n'est pas valide. Vérifier que le fichier n'est pas corrompu et que son extension correspond au format du fichier.
Bien entendu les fichiers en question s'ouvrent normalement si je les déplace dans le dossier Démarrage Excel, mais pas si je les remplace par leur alias. Une ouverture manuelle via l'alias fonctionne.

Un bon nombre de macros fonctionnant avec EXCEL 11 ne fonctionnement plus.
Ainsi, une petite macro destinée à ouvrir un classeur ne sait pas ouvrir le fichier car EXCEL annonce qu'il ne sait pas trouver le fichier ! J'ai recréé la macro en "enregistrant". Ça ne fonctionne pas davantage.

Je précise que je suis sous macOS 10.12. Sierra et la version d'Office 16 est la dernière, mise à jour il y a deux jours, et la fenêtre À propos d'Excel porte la version 15.39 (171010)

 

[Aliboron]

je m'apprête à passer à OFFICE 16, dont je n'utilise qu'EXCEL et, occasionnellement, WORD 16.

Petite précision : dans la mesure où il n'existe pas de version avec comme nom commercial "Office 16" (mais qu'il existe une beta avec le nom technique 16) on va considérer qu'il est question d'Office 2016 (et aussi d'Office 2011) dans ton message.

J'ai de gros problèmes avec Excel 2011.

Quels problèmes exactement ?

L'ouverture de classeur(s) au démarrage ne fonctionne plus si le nom de classeur est donné via un "alias". Un message indique alors :
Le format ou l'extension du fichier n'est pas valide. Vérifier que le fichier n'est pas corrompu et que son extension correspond au format du fichier.
Bien entendu les fichiers en question s'ouvrent normalement si je les déplace dans le dossier Démarrage Excel, mais pas si je les remplace par leur alias. Une ouverture manuelle via l'alias fonctionne.

Tiens, faudrait que je regarde ça (pas eu l'occasion). Il est possible que ça soit incontournable et que ça fasse partie de la mise en conformité avec les directives de fonctionnement en "bac à sable" imposée par Apple : les possibilités d'interaction des applications avec d'autres fichiers sont très restreintes.

Un bon nombre de macros fonctionnant avec Excel 2011 ne fonctionnement plus.
Ainsi, une petite macro destinée à ouvrir un classeur ne sait pas ouvrir le fichier car Excel annonce qu'il ne sait pas trouver le fichier ! J'ai recréé la macro en "enregistrant". Ça ne fonctionne pas davantage.

Il faudrait peut-être plus de précisions sur le contexte. Le code concerné, bien sûr, et l'emplacement où est enregistré le fichier concerné. Il y a en particulier des emplacements préservés maintenant, et une arborescence complexe, dans la Bibliothèque. Ce qui fait un changement.

 

[iluro_64]

Merci de ta promptitude à me répondre.
Je m'en tiens pour le moment aux alias. Je pense que ta piste du "bac à sable" est pertinente. Cela signifierait que pour ouvrir automatiquement des classeurs au démarrage, il faut absolument les "loger" dans le dossier "Démarrage Excel". Peut-être pourrait-on alors "loger" dans ce dossier une macro qui s'exécute à l'ouverture du classeur. Mais je pense que cette possibilité n'existe pas.
Pour apporter de l'eau à ton moulin, j'ai poussé un peu plus loin le problème de l'alias.

En double-cliquant sur l'alias d'un des classeurs, j'ai eu le message signalé dans mon premier message. Puis en cliquant à nouveau dessus, le classeur s'est ouvert ! C'est à cause de cela que j'ai plutôt pensé à un bug…

Je reviendrai sur le problème des macros plus tard, lorsque j'aurai fait des manip complémentaires.

 

[Aliboron]

Cela signifierait que pour ouvrir automatiquement des classeurs au démarrage, il faut absolument les "loger" dans le dossier "Démarrage Excel".

C'est ce que je dirais.

Peut-être pourrait-on alors "loger" dans ce dossier une macro qui s'exécute à l'ouverture du classeur. Mais je pense que cette possibilité n'existe pas.

Si, si, bien sûr. Il te faut enregistrer un classeur en .xlsm et mettre dans la feuille de code de ThisWorkbook une macro événementielle de ce type :

​

Ça fonctionne très bien, même si le "nouvel" éditeur VBA est pour le moment encore un peu incomplet et parfois instable.

 

[iluro_64]

Voilà matière à réflexion.
J'insiste sur le fait que tout marche correctement avec EXCEL 11 version 14.7.7 (170905) c'est-à-dire la dernière !

Message d'erreur à l'exécution du code ci-après avec EXCEL 16:

 

[Aliboron]

J'insiste (pour éviter les confusions) : Excel 11 n'est pas un nom commercial existant (pas plus qu'Excel 16). La version "11" d'Excel, c'est celle qui porte le nom Excel 2004. La version "16" est celle qui sera a priori lancée fin 2018 (et qui est en beta test actuellement) alors que la version "15" porte sur Mac le nom d'Excel 2016.

Excel 2016 n'utilise plus les deux-points comme séparateur (survivance de Mac OS 9 et précédents, qui avait été conservée par souci de compatibilité jusqu'à Excel 2011). Il faut dorénavant mettre les chemins d'accès avec les slashes (donc /Users/bernardXXXXX/Documents/Maison/Comptes/Relevé récapitulatif XXXX.xlsx").

Pour plus de précisions sur les soucis qu'on peut rencontrer avec Excel 2016 et le fonctionnement en bac à sable, tu peux utilement jeter un oeil sur les pages qu'y consacre Ron de Bruin.

 

[iluro_64]

OK pour les ":" à replacer par des "/". Je vais donc m'y atteler. Je pense que cela va permettre de redresser pas mal de dysfonctionnements.

Grand merci, donc. Je te tiens au courant.

J'ai mémorisé l'adresse de Ron de Bruin. Voilà de la bonne matière à l'ire

 

[iluro_64]

Ça y est, j'ai remplacé les ":" par des "/", mais aussi les "HD:Users:" par des "Users/".
Cela a redonné de la vitalité à toutes les macros qui présentaient cette "différence".

Lorsque je me suis attaqué au problème de l'ouverture de fichiers au démarrage d'Excel, je suis tombé sur deux problèmes de taille.
Le premier est que lorsqu'on enregistre une nouvelle macro, le code relatif à l'ouverture de classeur n'est plus enregistré, et que l'enregistrement n'est effectif que si le fichier est déjà ouvert.
Qu'à cela ne tienne, j'ai décidé de le faire "à la main" en prenant exemple sur les macros qui fonctionnent et en faisant du "copier-coller". C'est alors que le second problème est apparu, comme s'il y avait des différences de syntaxe au niveau d'options des instructions. Pas de problème, je recherche le manuel VBA Excel que j'avais quelque part sur le Mac. C'est alors que je me suis souvenu que lorsque j'avais acheté l'iMac actuel, j'avais tout réinstallé, mais pas nécessairement recopié tout l'ancien iMac. Je n'ai donc plus de manuel de référence.
Pour ce dernier point, aurais-tu un ouvrage à me conseiller ? Sur internet, j'en ai trouvé une flopée, dont une disponible en fichier PDF, et en français. J'ai cherché ce dont j'avais besoin, mais je n'ai pas trouvé.

 

[Aliboron]

lorsqu'on enregistre une nouvelle macro, le code relatif à l'ouverture de classeur n'est plus enregistré, et que l'enregistrement n'est effectif que si le fichier est déjà ouvert.

Je n'ai pas bien compris mais ce n'est a priori pas très important : les macros enregistrées ne peuvent servir que de brouillons. Il y a bien trop de scories, il faut toujours aller optimiser, supprimer des tas de trucs inutiles (des "Select" en pagaille, des "ActiveWindow.Scroll" qui ne servent à rien, etc.)

Pas de problème, je recherche le manuel VBA Excel que j'avais quelque part sur le Mac. C'est alors que je me suis souvenu que lorsque j'avais acheté l'iMac actuel, j'avais tout réinstallé, mais pas nécessairement recopié tout l'ancien iMac. Je n'ai donc plus de manuel de référence.

Ah, oui, vaste sujet. Comme il n'existe plus de guide depuis déjà un moment, c'est devenu un peu compliqué. Tu peux toujours télécharger le Manuel VBA d'Excel 2013 (en cherchant, il y en a peut-être d'autres...) mais bon, ce n'est pas vraiment génial : il faut lire ça sous Windows ou avec l'utilitaire CHM Reader. Sans compter qu'il ne faut pas s'enthousiasmer trop, il y a des fonctions qui n'existent pas dans la version pour Mac, d'autres qui ont des caractéristiques ou des paramètres différents...

Pour ce dernier point, aurais-tu un ouvrage à me conseiller ? Sur internet, j'en ai trouvé une flopée, dont une disponible en fichier PDF, et en français.

Non, je n'ai pas vraiment de livre en tête. Pour les cas vraiment compliqués, je lance une machine virtuelle avec Excel 2004 pour consulter l'aide (en sachant que certaines choses ont changé entre temps). Mais sinon, je fais une recherche au coup par coup.

J'ai cherché ce dont j'avais besoin, mais je n'ai pas trouvé.

De quoi avais-tu besoin exactement ?

 

[iluro_64]

Je reprends : enregistrement de macros
L'idée est d'obtenir du code bon du point de vue syntaxique, afin de le compléter ensuite , et de l'épurer des choses inutiles.
Toutes mes macros sont contenues dans un classeur unique spécialisé dans cette fonction. C'est donc un nom de classeur de forme " classeur_de_macros.xlsm".

Lors d'un enregistrement de macro, ce fichier est ouvert et c'est dans ce fichier que la macro sera enregistrée. Si la première instruction est " Ouvrir un fichier… ", et si l'enregistrement est arrêté ensuite, alors que le classeur est bien ouvert, le code de la macro ne comprend pas l'instruction VBA d'ouverture.



Suite : manuels de référence
J'ai téléchargé le Manuel VBA d'Excel 2013 et CHM Reader. Un peu lourd à manipuler, mais semblant très complet, même si c'est "très" formel.
J'ai aussi acheté un livre sur l'iBooks Store, " VBA pour Excel 2010, 2013 et 2016 ", moins complet mais généralement suffisant.

Fin : ce que je n'ai pas trouvé :
Je n'ai pas trouvé comment extraire les 4 chiffres de l'année de la date du jour, ou les 2 chiffres du mois, ni ceux ceux du jour.
Pour mois c'est très important, car tout le système de gestion que j'ai développé avec Excel pour ma comptabilité est basée sur les noms de classeur construits avec l'année, ou avec l'année et le mois.

 

[iluro_64]

J'ai trouvé ce qui me manquait. C'était pratiquement ce à quoi je pensai, mais en anglais, et dans le chapitre adéquat, GESTION DES DATES, bien développé dans l'e-book acheté

 

[Aliboron]

Oui, pour les dates, c'est assez simple : Year(Now) et Month(Now) te donnent les réponses attendues.

Pour ce qui est de l'ouverture de classeurs, une fois que tu sais que c'est Workbooks.Open "/Users/monnom/Desktop/etc" tu n'as pas d'intérêt particulier à ce que ce soit enregistré (même si c'est quand même un bug). Comme déjà vu, l'enregistrement des macros, si c'est "bon du point de vue syntaxique" (encore que) est à peu près inutilisable tel quel, sauf quelques cas bien particuliers.

 

[iluro_64]

Maintenant que " j'ai repris la main ", je vais me remettre à programmer les quelques macros dont j'ai besoin pour uniformiser les classeurs les plus anciens.

Je reviens sur le-Book que j'ai acheté. À l'usage, il est très pratique, grâce à une sommaire très détaillé qui facilite beaucoup les recherches, avec des titres comme gestion du temps, Gestion des dates, ou encore « OBJETS APPLICATION, CLASSEURS, FEUILLES ».

En ce qui concerne l'ouverture de classeurs au lancement d'Excel, je suis aussi sur la bonne voie. Je vais poursuivre par ce sujet pour terminer. Ensuite, si tout va bien, je des-installerai Office 2011 pour Mac. Mais sera toujours sur mon portable. Par contre je n'ai pas pu installer Office 2016. Il faut en effet passer par MS pour qu'un logiciel puisse être installé sur une seconde machine à cause du numéro de machine. À moins d'acheter une seconde licence (étudiant, maison).

 

[Aliboron]

C'est pour ça qu'il faut bien peser le pour et le contre entre la version définitive et la version par abonnement...

 

[iluro_64]

Je ne suis pas un fervent partisan de la " location ".
Quand on regarde les offre pour Office 365, l'on se rend compte qu'en location ce n'est pas si avantageux que cela. Dans le cas de la location, c'est soit 1 installation pour 5 membres utilisateurs, ou 1 installation pour 1 utilisateur. Dans le cas de l'achat définitif, c'est une seule installation, et le nombre d'utilisateurs n'intervient pas. Au bout de deux ans, on constate que l'offre 1 installation et 5 utilisateurs coûte 2 fois plus cher que le coût de l'achat, et l'offre pour une installation pour 1 utilisateur coûte presque aussi cher que le coût de l'achat (69x2=138 €, 149 €) de l'autre. Finalement, le coût d'achat de 2 licences est de 298 € à comparer aux 198 € au bout de deux ans et 297 € au bout de trois ans.

 

[iluro_64]

Décidément, je n'ai pas de chance.
Dans une nouvelle macro, j'utilise l'instruction : Selection.NumberFormat = "# ##0,00 €" qui correspond au choix du style Monétaire dans le menu déroulant des styles de données. Rien d'extraordinaire. Sauf que, au niveau de l'exécution, le résultat affiché est 2 283 € au lieu d'être 2 282,79 €.
Si j'utilise l'instruction ;
Selection.NumberFormat = "_ * # ##0,00_) €_ ;_ * (# ##0,00) €_ ;_ * ""-""??_) €_ ;_ @_ " qui correspond au choix du style Comptabilité. Le résultat est le même. Tout se passe comme s'il fallait, ensuite, ajouter une instruction pour ajouter deux décimales.

Quand tu parles d'instabilité, c'est un doux " euphémisme".

 

[Aliboron]

Il doit y avoir autre chose. Certes, le fait qu'il y ait Sélection dans l'instruction ne présage rien de bon. En tout cas, chez moi, je n'arrive pas à reproduire le problème :

​

 

[iluro_64]

Je vais modifier l'instruction en remplaçant Selection par Range.

Sub Style()

Range("J3").NumberFormat = "# ##0,00 €"

End Sub

Pas de chance, ça ne marche pas davantage

Précision pour le cas précédent : la sélection portait sur les colonnes E à J

Je me demande si je n'ai pas un bug quelque part.En effet, dans l'éditeur de macro, il m'est impossible de taper le caractère €. Il faut que je le tape ailleurs et que je fasse un copier-coller ensuite.

 

[Aliboron]

Précision pour le cas précédent : la sélection portait sur les colonnes E à J

Tout dépend de ce qu'il y a comme code auparavant. Mais dans 99% des cas le recours à Selection est inutile (ça sent vraiment le résidu de macro enregistrée). Pour que la modification porte sur tes colonnes E à J, tu saisis :
Range("E:J").NumberFormat = "# ##0,00€" et le tour est joué. Enfin, chez moi ça marche (mais je suis en version 16.7, étant inscrit comme "Insider Fast")

dans l'éditeur de macro, il m'est impossible de taper le caractère €. Il faut que je le tape ailleurs et que je fasse un copier-coller ensuite.

Oui, dans le nouvel éditeur VBA, tout n'est pas encore bien en place. En particulier les caractères non américains posent problème (par exemple la saisie du é qui devient È, du è qui devient Ë et sans parler de l'accent circonflexe qui ouvre un champ de saisie annexe - dans lequel on peut saisir les caractères accentués, cette fois). En principe, c'est résolu dans la prochaine mise à jour, ça.

 

[iluro_64]

J'ai trouvé une solution pour régler ce problème de manière très " élégante "
Quelle que soit la syntaxe utilisée ça fonctionne.
Le VBA que j'utilise est liée à la définition locale des représentations des dates et des nombres.
Lorsqu'on utilise NumberFormat la représentation par défaut est la langue anglaise. L'unité monétaire est $, l'abréviation de "jour " n'est "j" mais celle de "day", donc "d".
Je ne sais pas s'il s'agit d'une nouvelle instruction mais NumberFormatLocal résoud le problème.
Ci-dessous le texte de la macro de test :



Cela signifie que l'enregistreur de macros n'enregistre pas tout à fait la réalité des actions, car il ne tiens pas compte de leur localisation. Cela me surprend à moins qu'il y ait une "préférence" à préciser quelque part. Dans mes lectures récentes, j'ai vu qu'il y avait des parties de VBA en langue française. Mais peut-être que cela ne s'applique qu'à la version Windows.