Discussion :

[Tibaldus]

Salut à tous !!!
J'ai développé une petite application en Visual Basic, qui utilise Word pour créer des rapports de résultats.
Le problème c'est que, en fonction de la version de Office installée, je n'utilise pas exactement le même code (merci Microsoft... ).
J'aimerai donc inclure dans le fichier Setup (crée avec Inno Setup) un test pour savoir quelle version d'Office est présente sur le poste, et ainsi installer les bons fichiers.

Je pense qu'il faut aller voir dans la base de registre, mais je ne sais pas où chercher... Quelqun saurait-il me dire si cette opération est possible, et comment procéder??

Merci d'avance,

Tibaldus

[Lou Pitchoun]

Salut,

Le problème c'est que, en fonction de la version de Office installée, je n'utilise pas exactement le même code (merci Microsoft... ).

Pourrais-tu donner plus de détails ? voire même un exemple de code qui fonctionne sur une version et son équivalent pour une autre version.

[Tibaldus]

Là tout de suite j'ai pas toutes les versions sur mon poste. C'est pas grand chose,... des fonctions qui ne fonctionnent plus, des mises en pages quelques peu différentes... ça serait long de tout expliciter!
Celà dit, je pense pas que ça puisse aider à répondre à mon problème... Ce qui m'interesse surtout, c'est comment aller chercher la version d'office.

A plus,

Tibaldus

[Maxence HUBICHE]

Utilises la propriété Version de l'objet Application

[ucfoutu]

Bonjour,

J'ouvrirais personnellement la clé (de la BDR) :

HKEY_CURRENT_USER\Software\Microsoft\Microsoft Office

et lirais la 1ère sous-clé.

[Heureux-oli]

Bonjour,

J'ouvrirais personnellement la clé (de la BDR) :

HKEY_CURRENT_USER\Software\Microsoft\Microsoft Office

et lirais la 1ère sous-clé.

Il est plus facile d'utiliser

Application.Version que d'ouvrir la BDR !

Pour Word 2007 => 12.0

[ucfoutu]

Certes,

Encore faut-il :

1) pouvoir ouvrir un document
2) qie l'on puisse exécuter cette commande

Travailler à posteriori n'est pas toujours la solution...... Il peut arriver que ce soit déjà trop tard...

Je rappelle ici (en rouge) l'essentiel de la demande :

J'ai développé une petite application en Visual Basic, qui utilise Word pour créer des rapports de résultats.
Le problème c'est que, en fonction de la version de Office installée, je n'utilise pas exactement le même code (merci Microsoft... ).
J'aimerai donc inclure dans le fichier Setup (crée avec Inno Setup) un test pour savoir quelle version d'Office est présente sur le poste, et ainsi installer les bons fichers.

Il est donc ici demandé de pouvoir déterminer cette version lors même de l'exécution d'un Setup.exe de VB (et pas lors de l'ouverture d'un fichier MsOffice...

Aurais-je lu trop vite ?
Que l'on me pende, si tel est le cas !

[Heureux-oli]

Il n'est important de connaître les fichiers que si tu utilises des bibliothèques.

Un code dans Word reste dans Word et Application.Version fonctionne quoi qu'il se passe.

C'est beau de dire qu'il faut ouvrir la BDR, tu n'explique pas comment ni ne lui donne de lien.
En plus, si tu fais du latebinding, c'est encore plus facile.

[Maxence HUBICHE]

on peut aussi considérer la génération de l'objet application en LateBinding
(no problemo)
Et, en fonction de ObjetApplication.Version, appeler une classe plutôt qu'une autre... ou même faire une classequi utilise une variable publique déclarée au démarrage de l'application, qui reprend la version,et utiliser en permanence cette variable.

Ca marche bien, je pense... non ?

[ucfoutu]

Re,

1) C'est depuis VB (il a posté dans la mauvaise section ) qu'il doit ouvrir la BDR, pas depuis MsOffice (son programme est un programme VB, pas VBA, et son Setup l'est également.
2) Ce qu'il faut pour lire/écrire/manipuler la base de registre (sources et exemples) ne manque absolument pas dans la section VB ..... (c'est plus que complet)...

Rappel (à nouveau) : il installe les fichiers adéquats lors du Setup (c'est à dire lors de l'exécution du fichier d'installation de son application).

Et de là à ce que, en plus, il pilote depuis VB des applications VBA, ma foi ... il n'y a qu'un tout petit pas ...

Mais laissons-le nous dire ....... ce sera bien...

[Heureux-oli]

Re,

1) C'est depuis VB (il a posté dans la mauvaise section ) qu'il doit ouvrir la BDR, pas depuis MsOffice (son programme est un programme VB, pas VBA, et son Setup l'est également.
2) Ce qu'il faut pour lire/écrire/manipuler la base de registre (sources et exemples) ne manque absolument pas dans la section VB ..... (c'est plus que complet)...

Rappel (à nouveau) : il installe les fichiers adéquats lors du Setup (c'est à dire lors de l'exécution du fichier d'installation de son application).

Et de là à ce que, en plus, il pilote depuis VB des applications VBA, ma foi ... il n'y a qu'un tout petit pas ...

Mis laissons-le nous dire ....

Mais c'est pour une appli Office existante. Donc il suffit de faire du latebinding.

[Maxence HUBICHE]

Re,

1) C'est depuis VB (il a posté dans la mauvaise section ) qu'il doit ouvrir la BDR, pas depuis MsOffice (son programme est un programme VB, pas VBA, et son Setup l'est également.

Je croyais qu'en VB aussi on faisait

Code :

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

1
2
3
 
Dim monAppli as Object
Set monAppli = CreateObject("Word.Application")

Car, après tout, il y a bien la bibliothèque VBA dans tout projet VBA...

[ucfoutu]

S'il "pilote", son code de pilotage est écrit dans son application VB.

1) Je crois vraiment qu'il convient que le demandeur éclaicisse ces points.

2) Ton dernier message, Maxence Hubiche, ne peut s'appliquer au setup.exe qui, lui, n'est certes pas l'exe de son appli ...!!!

[Maxence HUBICHE]

Non pas au setup.exe
Mais à son programme en lui-même, ce qui lui évite le développement de fichiers multiples à charger, plus le développement d'un setup un peu particulier, et qui garantit qui plus est une évolutivité des plus intéressantes