Discussion :

[Ender75]

Bonjour,

Pour une appli C++ sous VS 2010, je cherche à créer des fichiers Excel (pas des CSV car besoin de formatage de cellule).
Désolé par avance si je ne suis pas dans le bon forum.

J'ai vu qu'on pouvait passer entre autre par Automation Office par des smart Pointer (Import Directive) ou par appels directs à des services COM.
A priori la technique par Smart Pointer me semble plus simple que la technique par services COM (Pour ce dernier, à première vue le code pique les yeux...).

En revanche, à moins que j'ai mal compris, avec les smart pointer, il faut explicitement déclarer une version d'Excel précise.
par exemple #import "C:\\Program Files\\Microsoft Office\\Office12\\EXCEL.EXE" \

Ca me semble contraignant question pérennité, il suffit qu'une nouvelle version d'Excel soit installée pour que cela cesse de fonctionner.

Il y a un moyen de contourner cette contrainte ? Des import conditionnés par version d'Excel ?

Sinon, bah utiliser les services COM et serrer les dents

Merci de votre réponse et bonne journée.

[bacelar]

Pour moi, "smart Pointer", cela n'a rien à voir avec "Import Directive".
Donc je remplace "smart Pointer" par "Import Directive". (dans ma tête, oui je sais, ça n'aidera pas ma schizophrénie latente)

appels directs à des services COM

Les Services COM, c'est vague, très vague, vous voulez vraisemblablement parler d'ATL ou de l'API COM (une API en C à la Win32), non ?

"#import", c'est juste un truc pour nous faciliter la vie.
Vous avez les mêmes limitations qu'avec ATL et COM(de base).

Le seul truc, c'est qu'en ATL et en COM, vous en chiez tellement, que la gestion du versionning, c'est pas plus compliquer que le reste.

Vous ne pourrez pas espérer avoir du code qui fonctionne avec les versions ultérieures de produit, si les concepteurs du dit produit n'ont pas assuré la compatibilité ascendante.

Donc, si la nouvelle version d'Office assure la compatibilité avec la version "Office12", votre code fonctionnera sans accro.
Il ne pourra pas utiliser les nouvelles fonctionnalités de la nouvelle version, mais c'est tout.

Si la nouvelle version n'assure pas de compatibilité, là, ça coince, mais aussi bien avec #import qu'avec ATL/COM.
Si vous disposez de la TLB de la nouvelle version, rien ne vous empêche de faire plusieurs #import, mais attention aux collisions de noms.
Une petite tambouille pour que le #import soient dans un "namespace{...}" différents (ou l'utilisation judicieuse des options de #import) pour éviter ces collisions et le tour est joué.
Avec ATL/COM, vous ferez toute cette tuyauterie à la main, mais les limitations sont les mêmes, le TLB doit être connu à l'avance.
Le seul avantage d'ATL/COM, c'est que vous n'avez pas besoin de la TLB sous la main, mais dans une documentation blindée de GUID dans tous les coins.

Que cela soit avec #import ou ATL/COM, vous ne pouvez pas être compatible avec une version "Alien" venant du turfu de SkyNet.

Mais bon, on ne va pas se mentir, utiliser Excel pour créer des fichiers ".xlsx", c'est une super très mauvaise idée.

Le format des fichiers ".xlsx" n'est pas propriétaire, contrairement aux fichiers ".xls".
Donc, contrairement aux fichiers ".xls" où l'on devait utiliser des composants pondus à coups de reverse-engineering tout moisi, on dispose de l’embarras du choix des SDKs/frameworks/composants pour la génération de fichiers ".xlsx".
Comme énormément de ces composants se basent sur .NET et que l'utilisation de code C++/CLI depuis VS est des plus aisé, je vous conseille de le faire en C++/CLI.
SDK officiel pour Office :https://www.microsoft.com/en-us/down....aspx?id=30425

[Médinoc]

Pour moi, "smart Pointer", cela n'a rien à voir avec "Import Directive".

C'est fort dommage, parce que la directive #import déclare, en plus des interfaces COM, des pointeurs intelligents vers celles-ci.
Et ce, indépendamment d'ATL: Il s'agit à la place du Compiler COM Support, qui contrairement à ATL, est pris en charge par les éditions Express de Visual Studio.

En revanche, à moins que j'ai mal compris, avec les smart pointer, il faut explicitement déclarer une version d'Excel précise.
par exemple #import "C:\\Program Files\\Microsoft Office\\Office12\\EXCEL.EXE" \

Ca me semble contraignant question pérennité, il suffit qu'une nouvelle version d'Excel soit installée pour que cela cesse de fonctionner.

Il y a un moyen de contourner cette contrainte ? Des import conditionnés par version d'Excel ?

Si j'en crois la documentation de la directive #import, tu peux importer en spécifiant le ProgID d'un objet supporté par la TypeLib (Au hasard: Excel.Application) plutôt que d'avoir à faire quoi que ce soit de spécifique à une version ou à un chemin sur le disque.
Mais ça ne marche pas pour Excel, car ses objets n'ont pas de lien vers la typelib dans le registre.

Il te reste l'option d'utiliser le LibID à la place, parce qu'apparemment, contrairement aux CLSID, celui-ci ne change pas d'une version à l'autre.

Donc, un #import "libid:00020813-0000-0000-C000-000000000046" devrait marcher (malheureusement il ne suffit pas).

Après quelque recherches sur Internet, j'ai réussi à trouver les bonnes directives d'import:

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
#include <Windows.h>
#include <stdio.h>
 
#import "libid:2DF8D04C-5BFA-101B-BDE5-00AA0044DE52" rename("DocumentProperties", "MSODocumentProperties") rename("RGB", "MSORGB") //MSO.dll
#import "libid:0002E157-0000-0000-C000-000000000046" no_namespace rename("Reference", "ignorethis"), rename("VBE", "testVBE") //VBE6Ext.olb
#import "libid:00020813-0000-0000-C000-000000000046" exclude("IFont", "IPicture") rename("RGB", "ignorethis"),\
	rename("DialogBox", "ignorethis"), rename("VBE", "testVBE"), rename("ReplaceText", "EReplaceText"), rename("CopyFile","ECopyFile"),\
	rename("FindText", "EFindText"), rename("NoPrompt", "ENoPrompt") //Excel.exe
 
int main(void)
{
	return 0;
}

Il est possible que certains des exclude() et rename() soient superflus, notamment sur les deux derniers imports.

[Ender75]

Merci beaucoup Bacelar et Médinoc pour vos réponses détaillées !

@Bacelar
J'ai utilisé le terme de smart pointers parce que cela faisait référence dans une page du FAQ
https://cpp.developpez.com/faq/vc/?p...sual-Cplusplus

Pour les services COM, la solution proposée est d'utiliser les IDispatch et les fonctions Invoke.
En tout cas, c'est assez indigeste.

Donc, si la nouvelle version d'Office assure la compatibilité avec la version "Office12", votre code fonctionnera sans accro.
Il ne pourra pas utiliser les nouvelles fonctionnalités de la nouvelle version, mais c'est tout.

Je connais assez mal comment fonctionne ces répertoires d'Office / librairies
Est-ce ces répertoires/Librairies seront créés à l'installation d'une version ultérieure qui assure la compatibilité descendante ?

Une petite tambouille pour que le #import soient dans un "namespace{...}" différents (ou l'utilisation judicieuse des options de #import) pour éviter ces collisions et le tour est joué.

Et je ne suis pas très à l'aise non plus sur les import (ok je cumule...) et namespace , quelle est cette tambouille en question ?

@Médinoc
Oui j'avais vu qu'on pouvait utiliser les libid, ça me semble effectivement plus propre.

Encore merci à tous les deux d'avoir consacré du temps à me répondre !

[Médinoc]

Utiliser IDispatch? Toutes les interfaces d'Excel sont duales, utiliser la version late-bound est une pure perte de temps et d'efficacité pour un programme en C++: ces versions sont prévues pour des langages de script. Utilise les interfaces normales, les smart pointers générés par #import sont faits pour ça.

[Ender75]

Utiliser IDispatch? Toutes les interfaces d'Excel sont duales, utiliser la version late-bound est une pure perte de temps et d'efficacité pour un programme en C++: ces versions sont prévues pour des langages de script. Utilise les interfaces normales, les smart pointers générés par #import sont faits pour ça.

En regardant dans les forums (y compris la FAQ de ce site), c'était l'une des 3 méthodes proposées.

Mais sinon oui je compte utiliser les smart pointers parce que les services COM, ça m'avait semblé franchement pénible à coder.

Merci pour le conseil, ça me conforte dans cette solution