Problème de compatibilité entre les version d'Excel ?
2 réponses
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
Files\Fichiers communs\Microsoft Shared\VBA... 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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Michel Pierron
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}
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" a écrit dans le 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
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}
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" <pierre.archambault@videotron.ca> a écrit dans le
message de news:KfIqd.40925$5J.900373@wagner.videotron.net...
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
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}
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" a écrit dans le 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
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
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.
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.
