Problème de compatibilité entre les version d'Excel ?

Le
Pierre Archambault
Bonjour,

J'ai développé une application Excel VBA qui roule sous Windows 2000 Pro et
Office 2000 Pro. J'ai également utilisé des contrôles qui ne sont
disponibles qu'après l'installation de Visual Basic 6.0 Édition entreprise.

J'ai apporté une copie de ce classeur chez mon frère qui lui, est sous
Windows XP SP2 et Office 2003. J'avais prévu apporter aussi les fichiers
.OCX qui risquaient de manquer sur son PC, mais le problème est venu
d'ailleurs

Les lignes de code qui contenaient des instruction de manipulation de chaîne
telles que : Left, Right, Mid, Format etc. provoquaient des erreurs. Je ne
me souviens pas du message d'erreur mais je crois qu'il s'agissait de
référence manquante. Quoiqu'il en soit, j'ai vérifié la liste des références
disponibles sur le PC de mon frère (Menu Outils, Références) et je n'ai
vu aucune ligne indiquant que l'une d'elle était manquante.

J'ai alors ajouté dans le code, le mot "VBA." devant chacune des
instructions problématiques et curieusement, la compilation ne posait plus
de problème. Vais-je devoir toujours utiliser ce subterfuge si mes
application doivent être transportées d'un environnement à l'autre ? Que
manque-t-il sur le PC de mon frère ? Que puis-je faire pour que je n'ai plus
à coder ainsi ?

Première sous question: Dans la boîte de dialogue Outils | Références, quand
je clique sur une référence de la liste, le chemin d'accès du fichier
apparaît dans un cadre au bas de la liste. Or il arrive que ce chemin soit
plus long que la largeur de la fenêtre et il devient alors impossible de
lire le nom du fichier. Par exemple, pour Microsoft Visual Basic for
Applications Extensibility 5.3, le chemin affiché est : C:Program
FilesFichiers communsMicrosoft SharedVBA le reste est tronqué. Il est
donc impossible de savoir si ce fichier est absent sur le système en
question.

Deuxième sous question: Comment savoir si les références cochées sont
vraiment indispensables au bon fonctionnement du programme ? Les références
inutiles font-elles en sorte que le fichier prenne inutilement du poids ?

Pardonnez la longueur mais je préfère donner des explications claires plutôt
que de devoir préciser encore et encore.

Merci de votre aide.

Pierre
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Michel Pierron
Le #1945742
Bonsoir Pierre;
De base pour un nouveau classeur dans une session vierge, tu as d'office les
références suivantes pour xl2002:
VBA 4.0
Visual Basic For Applications
intégré (TypeLib) - Référence intacte
C:Program FilesFichiers communsMicrosoft SharedVBAVBA6VBE6.DLL
{000204EF-0000-0000-C000-000000000046}

Excel 1.4
Microsoft Excel 10.0 Object Library
Intégré (TypeLib) - Référence intacte
C:Program FilesMicrosoft OfficeOffice10EXCEL.EXE
{00020813-0000-0000-C000-000000000046}

stdole 2.0
OLE Automation
Personnalisé (TypeLib) - Référence intacte
C:WINDOWSSystem32stdole2.tlb
{00020430-0000-0000-C000-000000000046}

Office 2.2
Microsoft Office 10.0 Object Library
Personnalisé (TypeLib) - Référence intacte
C:Program FilesFichiers communsMicrosoft SharedOffice10MSO.DLL
{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}

Il est évident que pour xl2003, dans les descriptifs ci-dessus, 10 deviendra
11.

Si tu ajoutes un UserForm, la référence suivante est automatiquement
activée:
MSForms 2.0
Microsoft Forms 2.0 Object Library
Personnalisé (TypeLib) - Référence intacte
C:WINDOWSSystem32FM20.DLL
{0D452EE1-E08F-101A-852E-02608C4D0BB4}

Si tu coches la référence à Microsoft Visual Basic for Applications
Extensibility 5.3 (qui au passage aurait du être Microsoft Visual Basic 6.0
Extensibility puisque tu as xl2002) la référence suivante est ajoutée:
VBIDE 5.3
Microsoft Visual Basic 6.0 Extensibility
Personnalisé (TypeLib) - Référence intacte
C:Program FilesMicrosoft Visual StudioVB98VB6EXT.OLB
{EF404E00-EDA6-101A-8DAF-00DD010F7EBB}

Cette dernière référence est la plupart du temps inutile, car elle ne sert
qu'à transcrire des noms de variable en leur valeur de constante; avec un
minimum de précaution, on peut donc s'en dispenser.

Pour un classeur donné, si tu souhaites récupérer la liste des références
utilisées, tu peux utiliser une procédure du genre:
Private Sub GetProjectReferences(ByVal Wbk$)
Dim oRef As Object, sType$, i&
Workbooks.Add
Cells(1, 1) = Workbooks(Wbk).FullName
Cells(1, 1).Font.Bold = True
i = 1
For Each oRef In Workbooks(Wbk).VBProject.References
With oRef
i = i + 1
Cells(i, 1) = .Name & " " & .Major & "." & .Minor
Cells(i, 1).Font.Bold = True
If Not .IsBroken And .Description <> "" Then
i = i + 1: Cells(i, 2) = .Description
End If
If .BuiltIn Then sType = "Intégré (" Else sType = "Personnalisé ("
i = i + 1
Select Case .Type
Case 1: sType = sType & "Projet)"
Case 0: sType = sType & "TypeLib)"
End Select
If .IsBroken Then
sType = sType & " - Référence rompue"
Else
sType = sType & " - Référence intacte"
End If
Cells(i, 2) = sType
i = i + 1: Cells(i, 2) = .FullPath
If .Type = 0 Then: i = i + 1: Cells(i, 2) = .GUID
End With
i = i + 1
Next
Columns("A:A").ColumnWidth = 2
End Sub

Pour savoir si les références cochées sont indispensables, compile ton
projet jusqu'à l'absence d'erreur, puis décoche les références une par une
et refait une compilation; si tu obtiens une erreur, cette dernière est
indispensable. Dans ton cas, hormis les références à Microsoft Excel 10.0
Object Library et Microsoft Office 10.0 Object Library qui passent à 11.0
pour xl2003 plus les ocx spécifiques (au passage, je ne suis pas sur que ce
soit une bonne idée car il faudra les installer sur les postes utilisateurs
et put être sont-ils soumis à l'installation préalable de Visual Basic 6.0),
je ne vois pas pourquoi la référence à Visual Basic For Applications
poserait problème.

MP

"Pierre Archambault" message de news:KfIqd.40925$
Bonjour,

J'ai développé une application Excel VBA qui roule sous Windows 2000 Pro
et

Office 2000 Pro. J'ai également utilisé des contrôles qui ne sont
disponibles qu'après l'installation de Visual Basic 6.0 Édition
entreprise.


J'ai apporté une copie de ce classeur chez mon frère qui lui, est sous
Windows XP SP2 et Office 2003. J'avais prévu apporter aussi les fichiers
.OCX qui risquaient de manquer sur son PC, mais le problème est venu
d'ailleurs...

Les lignes de code qui contenaient des instruction de manipulation de
chaîne

telles que : Left, Right, Mid, Format etc. provoquaient des erreurs. Je ne
me souviens pas du message d'erreur mais je crois qu'il s'agissait de
référence manquante. Quoiqu'il en soit, j'ai vérifié la liste des
références

disponibles sur le PC de mon frère (Menu Outils, Références...) et je n'ai
vu aucune ligne indiquant que l'une d'elle était manquante.

J'ai alors ajouté dans le code, le mot "VBA." devant chacune des
instructions problématiques et curieusement, la compilation ne posait plus
de problème. Vais-je devoir toujours utiliser ce subterfuge si mes
application doivent être transportées d'un environnement à l'autre ? Que
manque-t-il sur le PC de mon frère ? Que puis-je faire pour que je n'ai
plus

à coder ainsi ?

Première sous question: Dans la boîte de dialogue Outils | Références,
quand

je clique sur une référence de la liste, le chemin d'accès du fichier
apparaît dans un cadre au bas de la liste. Or il arrive que ce chemin soit
plus long que la largeur de la fenêtre et il devient alors impossible de
lire le nom du fichier. Par exemple, pour Microsoft Visual Basic for
Applications Extensibility 5.3, le chemin affiché est : C:Program
FilesFichiers communsMicrosoft SharedVBA... le reste est tronqué. Il
est

donc impossible de savoir si ce fichier est absent sur le système en
question.

Deuxième sous question: Comment savoir si les références cochées sont
vraiment indispensables au bon fonctionnement du programme ? Les
références

inutiles font-elles en sorte que le fichier prenne inutilement du poids ?

Pardonnez la longueur mais je préfère donner des explications claires
plutôt

que de devoir préciser encore et encore.

Merci de votre aide.

Pierre




Frédéric Sigonneau
Le #1945689
Bonsoir,

Les lignes de code qui contenaient des instruction de manipulation de chaîne
telles que : Left, Right, Mid, Format etc. provoquaient des erreurs. Je ne
me souviens pas du message d'erreur mais je crois qu'il s'agissait de
référence manquante. Quoiqu'il en soit, j'ai vérifié la liste des références
disponibles sur le PC de mon frère (Menu Outils, Références...) et je n'ai
vu aucune ligne indiquant que l'une d'elle était manquante.


Les erreurs de compilation sur des mots clés de fonctions 'basiques' du langage
VBA ne viennent pas, la plupart du temps, d'un référence manquante à 'Visual
Basic For Applications' mais +tôt de l'absence d'un composant additionnel
correctement enregistré (et ajouter la référence à la bibliothèque VBA dans ton
code ne règle pas 'proprement', ni même sans doute définitivement, le problème,
AMA).
C'est sans doute, les ocx que tu as tenté d'installer sur le pc qui ne les a pas
d'origine (fournis avec Visual Basic ou Visual Studio par ex) qui posent
problème. Si tu as l'intention de déployer ton application au-delà du seul poste
de ton frère, il va falloir que tu trouves un moyen de te passer de tes
contrôles supplémentaires ou que la configuration minimale requise pour utiliser
ton application comprenne d'origine les ocx dont tu as besoin.

FS
---
Frédéric Sigonneau [MVP Excel - né un sans-culottide]
Gestions de temps, VBA pour Excel :
http://frederic.sigonneau.free.fr
Si votre question sur Excel est urgente, évitez ma bal !

Bonjour,

J'ai développé une application Excel VBA qui roule sous Windows 2000 Pro et
Office 2000 Pro. J'ai également utilisé des contrôles qui ne sont
disponibles qu'après l'installation de Visual Basic 6.0 Édition entreprise.

J'ai apporté une copie de ce classeur chez mon frère qui lui, est sous
Windows XP SP2 et Office 2003. J'avais prévu apporter aussi les fichiers
..OCX qui risquaient de manquer sur son PC, mais le problème est venu
d'ailleurs...

Les lignes de code qui contenaient des instruction de manipulation de chaîne
telles que : Left, Right, Mid, Format etc. provoquaient des erreurs. Je ne
me souviens pas du message d'erreur mais je crois qu'il s'agissait de
référence manquante. Quoiqu'il en soit, j'ai vérifié la liste des références
disponibles sur le PC de mon frère (Menu Outils, Références...) et je n'ai
vu aucune ligne indiquant que l'une d'elle était manquante.

J'ai alors ajouté dans le code, le mot "VBA." devant chacune des
instructions problématiques et curieusement, la compilation ne posait plus
de problème. Vais-je devoir toujours utiliser ce subterfuge si mes
application doivent être transportées d'un environnement à l'autre ? Que
manque-t-il sur le PC de mon frère ? Que puis-je faire pour que je n'ai plus
à coder ainsi ?

Première sous question: Dans la boîte de dialogue Outils | Références, quand
je clique sur une référence de la liste, le chemin d'accès du fichier
apparaît dans un cadre au bas de la liste. Or il arrive que ce chemin soit
plus long que la largeur de la fenêtre et il devient alors impossible de
lire le nom du fichier. Par exemple, pour Microsoft Visual Basic for
Applications Extensibility 5.3, le chemin affiché est : C:Program
FilesFichiers communsMicrosoft SharedVBA... le reste est tronqué. Il est
donc impossible de savoir si ce fichier est absent sur le système en
question.

Deuxième sous question: Comment savoir si les références cochées sont
vraiment indispensables au bon fonctionnement du programme ? Les références
inutiles font-elles en sorte que le fichier prenne inutilement du poids ?

Pardonnez la longueur mais je préfère donner des explications claires plutôt
que de devoir préciser encore et encore.

Merci de votre aide.

Pierre




Publicité
Poster une réponse
Anonyme