C++ XE5, office 2013, pilotage par TWordApplication

Hello

Mon but est de pouvoir, sous XE5 en C++, piloter Word 2013 comme je le faisais avec XP et 2000
Alors j'ai trouvé un bon tuto pour generer les composants pour Office2010
http://francois-piette.blogspot.com/...om-delphi.html
ça marche tres bien pour XE5 Delphi
mais meme en cochant la case générer les .hpp pour C++
et bien, la compilation sous C++ d'une appli toute simple (un bouton et TWordApplication) génère plein d'erreur


pbs in VBIDE2010.hpp
[bcc32 Erreur] VBIDE2010.hpp(51): E2275 { attendu
Contexte d'analyseur complet
Unit1.cpp(6): #include Unit1.h
Unit1.h(11): #include c:\Users\Public\Documents\RAD Studio\12.0\hpp\Word2010.hpp
Word2010.hpp(18): #include c:\Users\Public\Documents\RAD Studio\12.0\hpp\Office2010.hpp
Office2010.hpp(17): #include c:\Users\Public\Documents\RAD Studio\12.0\hpp\VBIDE2010.hpp
VBIDE2010.hpp(29): namespace Vbide2010




dans le fichier VBIDE2010.hpp :


__interface _Windows;
typedef System::DelphiInterface<_Windows> _di__Windows;
typedef _di__Windows Windows;


Une aide serait la bienvenue car je bloque là
Merci

Bonjour,

Je n'utilise jamais ces composants. J'ai toujours eu des problèmes de ce genre.
On peut piloter Word et Excel par OLE et l'avantage c'est que ça fonctionne quel que soit la version d'office installée.
Mais il faut faire plus de code.

Cette solution peut-elle convenir ?

Merci pour ta réponse,
oui je sais pour OLE
j'avais même fait un tuto, y a quelques années sur ça
http://www.baghli.com/bcb_ole.php
mais bon, je préfère le TWordApplication, ça fait plus propre et lisible comme code

Ce qui m'embête c'est que ça marche super bien en Delphi mais pas avec C++ builder, sur des .hpp que le compilateur a lui même généré !
Merci
Lotfi

Pour la lisibilité du code, c'est parce que tu ne fais pas assez de factorisation.
Il faut se créer une série de fonctions qui rendent le code plus lisible en englobant l'OLE dedans.
Une fois les 4 ou 5 fonctions créées, c'est beaucoup plus simple à utiliser et à lire.

Je ne vois pas vraiment
tu as un exemple de code que tu as fait, par rapport à mon tuto, par exemple ?
Merci

Devoir gérer l'algorithme en même temps que l'automation est une mauvaise idée.
Il faut les séparer.

Par exemple, créé des fonctions du style :

Code:

---

1 2	SetParagraph(String Texte_P, TFont Font_P) SetTableCell(String Cellule_P, String Texte_P, TFont Font_P)

---

La modification, optimisation et correction du code de gestion de Word est ainsi centralisé et plus facile à maintenir.
La partie fonctionnelle du logiciel est décorrélée de la gestion de Word et de la complexité du code. L'algorithme est plus simple à lire, écrire et maintenir.

La perte de performance dû à la gestion des différents cas dans chaque fonction est compensée par la sécurisation (notamment vis à vis des failles et dépassement de mémoire) plus aisée du code.

Dès qu'un projet prend de l'ampleur et que le code n'est pas très lisible pour quelqu'un qui n'en ai pas l'auteur, j'englobe toute la gestion de ce type de composants dans des fonctions simples à comprendre. Quand on doit travailler sur ce type de code quelques années après, on est très content de l'avoir fait.

Et n'avoir que quelques fonctions à maintenir permet de se passer de ce type de composant en utilisant directement OLE sans difficultés insurmontables.

merci