Salut à tous,    
 
je suis en charge de maintenir un executable Visual Basic (developpé sous VB 6)  qui pilote des classeurs Excel via la Microsoft Excel Object Library 8.0 (excel 97). Celui-ci utilise simplement des fichiers .txt comme data d'entrée, l'executable parse celui ci, met en forme les diverses feuilles d'excel (graphique compris) résultante et insere les données du fichier ... jusque là tout va bien.    
 
MON PROBLEME :
------------------
 
J'avais déjà rencontré des problèmes de compatibilité entre les diverses versions d'Excel avec un autre executable du même genre (son code sert d'ailleurs de base sur le nouvel executable) et celà venait de la version de l'OLB d'EXCEL utilisé lors de la compilation (onglet "references" dans VB6). J'avais donc compilé en version EXCEL8 pour "assurer" la compatibilité ascendante vers les autres versions d'office et ca fonctionnait pour cet executable.... mais pas pour le nouveau !!! Je n'arrive pas a faire fonctionner mon executable (compilé avec Excel8) sous excel 97 / windows XP sp2 ou encore excel 2000 / win 2000...   . En revanche, il fonctionne très bien sur Win XP SP2 / excel 2003 ou encore Win XP SP2 / excel 2000
 
             
MA QUESTION :  
-------------------
 
Comment créer un executable (compilé sous VB6) qui est capable de piloter toutes les versions d'EXCEL et qui ne soit pas dépendant de la version de Windows ?    
 
Les contraintes de compatibilité : toutes les versions d'EXCEL (depuis 97 à aujourd'hui)
                                              tous les windows (depuis 98 à maintenant y compris NT)
 
J'ai bien utilisé " l'assistant d'empaquetage et déploiement " fourni avec VB6 mais rien n'y fait ... CA NE MARCHE PAS !!!    
 
Avez vous une solution concrete à me donner ?    
 
Je ne sais plus quoi faire ET je désepere !!    
 
Merci d'avance pour vos réponses.

Le référencement à des objets Excel97 est une galère sans nom pour une installation compatible avec des versions ultérieures.
J'ai eu à gérer ce genre de compatibilité entre un projet VBA Excel (97 à 2003) et MS Word en OLE Automation. Une solution est de créer la référence vers Excel97 (donc un PC avec cette version persistante et aucune autre !) et de laisser le lien se réactualiser sur la machine cible. Évidemment cela ne marche pas pour tous les objets à référencer.
 
Une autre solution est de développer le projet sans référencer d'ojet externe et de faire les liens par prototypage des fonctions comme pour les API windows :  
Declare Function MaFonction Lib "\outilsvbperso.dll" Alias "FonctionQuiFaitTout" (ByVal nBufferLength As Long, ByVal lpBuffer As String) As Long
Ca n'est pas simple, ça ne marche pas pour tous composants externes (je ne sais pas si c'est adapté à OLE DB), et encore faut-il connaître le prototypage des fonctions à utiliser (plus facile sans doute pour OLE DB).
 
Sans compter que sous Win NT les comportements sont quelquefois très différents des autres OS.
 
Il me semble que le kit de déploiement peut gérer des fichiers système différents en fonction de la cible, mais je n'ai jamais pu trouver d'information précise sur cette possibilité qui, en plus, semblait relever du bricolage quand je m'y étais intéressé.
 
Bref je n'ai pas vraiment de solution à te proposer, mais je compatis sincèrement.

Franchement, je suis ennervé car les même compatibilités ascendante ne sont pas toujours opérationnelle chez Microsoft. Aux dernières nouvelles et après installation des udpates SR1 et SR2 pour office 97, mon executable sur WIN XP SP2 fonctionne enfin !!!!!!
 
En revanche et c'est là où franchement je suis ennervé, sur un Win 2000 avec un office 2000 (non à jour certes) CA NE FONCTIONNE TOUJOURS PAS !!!!  
 
Comment veut tu créer une appli générique pour tous les offices et tous les windows dans ce cas, je m'y perd complètement.
 
Tu as raison sur le réferencement unique vers EXCEL 8 (office 97), c'est ce que j'ai fait et en théorie c'est polyvalent ... sauf cas particulier bien sur !
 
Bref je suis pas dans la m... avec ces 2 programmes à maintenir et attend le pire, c'est que le developpeur originel lui avait carrement crée une feuille excel avec des macros qui faisait la même chose pour contourner les problèmes de compatibilité : en gros une bien belle misère.
 
Moi il est hors de question que je me casse les ... à maintenir et une feuille excel et un autre programme qui fait la même chose en VB. Je cherche donc l'alternative miracle !!!!!