Dans le cadre d'une application VBA sous Excel 2000 sur poste W2000pro SP4,
et afin de pouvoir mettre en oeuvre des connexions ADO j'ai intégré une
référence à
- "Microsoft ActiveX Data Objects 2.6 Library"
- C:Program FilesCommon FilesSystemADOmsado15.dll
Jusque la tout va bien...
Lors du déport de mon complément Excel (Addin) sur un autre poste
normalement également en Excel2000 W2000pro et SP4, deux problèmes se sont
présentés :
- la référence "Microsoft ActiveX Data Objects 2.6 Library" n'était pas
disponible
- la référence "Microsoft ActiveX Data Objects 2.5 Library" l'était mais
pointait sur un fichier dll portant le même nom "msado15.dll" que celui me
donnant "Microsoft ActiveX Data Objects 2.6 Library" sur le poste
d'origine... ! Par contre les dll pointant sur d'autres versions antérieures
de "Microsoft ActiveX Data Objects Library", v2.3 et 2.4 en l'occurrence
ne présentaient pas de défaut, elles portaient bien le même nom pour des
version identiques de "Microsoft ActiveX Data Objects Library".
Mes quelques questions...
- Qu'est-ce qui détermine les références disponibles sur un poste ? ou
autrement dit comment uniformiser différents postes au regard des références
disponibles, l'appli devant à terme être déployée sur 20 à 30 postes dont
certains à l'étranger...
- Est-ce à votre avis normale que la même dll pointe dans une machine sur
"Microsoft ActiveX Data Objects 2.6 Library" et sur "Microsoft ActiveX Data
Objects 2.5 Library" dans une autre ?
Merci pour votre contribution
@+ Alain79
Dans le cadre d'une application VBA sous Excel 2000 sur poste W2000pro SP4,
et afin de pouvoir mettre en oeuvre des connexions ADO j'ai intégré une
référence à
- "Microsoft ActiveX Data Objects 2.6 Library"
- C:Program FilesCommon FilesSystemADOmsado15.dll
Jusque la tout va bien...
Lors du déport de mon complément Excel (Addin) sur un autre poste
normalement également en Excel2000 W2000pro et SP4, deux problèmes se sont
présentés :
- la référence "Microsoft ActiveX Data Objects 2.6 Library" n'était pas
disponible
- la référence "Microsoft ActiveX Data Objects 2.5 Library" l'était mais
pointait sur un fichier dll portant le même nom "msado15.dll" que celui me
donnant "Microsoft ActiveX Data Objects 2.6 Library" sur le poste
d'origine... ! Par contre les dll pointant sur d'autres versions antérieures
de "Microsoft ActiveX Data Objects Library", v2.3 et 2.4 en l'occurrence
ne présentaient pas de défaut, elles portaient bien le même nom pour des
version identiques de "Microsoft ActiveX Data Objects Library".
Mes quelques questions...
- Qu'est-ce qui détermine les références disponibles sur un poste ? ou
autrement dit comment uniformiser différents postes au regard des références
disponibles, l'appli devant à terme être déployée sur 20 à 30 postes dont
certains à l'étranger...
- Est-ce à votre avis normale que la même dll pointe dans une machine sur
"Microsoft ActiveX Data Objects 2.6 Library" et sur "Microsoft ActiveX Data
Objects 2.5 Library" dans une autre ?
Merci pour votre contribution
@+ Alain79
Dans le cadre d'une application VBA sous Excel 2000 sur poste W2000pro SP4,
et afin de pouvoir mettre en oeuvre des connexions ADO j'ai intégré une
référence à
- "Microsoft ActiveX Data Objects 2.6 Library"
- C:Program FilesCommon FilesSystemADOmsado15.dll
Jusque la tout va bien...
Lors du déport de mon complément Excel (Addin) sur un autre poste
normalement également en Excel2000 W2000pro et SP4, deux problèmes se sont
présentés :
- la référence "Microsoft ActiveX Data Objects 2.6 Library" n'était pas
disponible
- la référence "Microsoft ActiveX Data Objects 2.5 Library" l'était mais
pointait sur un fichier dll portant le même nom "msado15.dll" que celui me
donnant "Microsoft ActiveX Data Objects 2.6 Library" sur le poste
d'origine... ! Par contre les dll pointant sur d'autres versions antérieures
de "Microsoft ActiveX Data Objects Library", v2.3 et 2.4 en l'occurrence
ne présentaient pas de défaut, elles portaient bien le même nom pour des
version identiques de "Microsoft ActiveX Data Objects Library".
Mes quelques questions...
- Qu'est-ce qui détermine les références disponibles sur un poste ? ou
autrement dit comment uniformiser différents postes au regard des références
disponibles, l'appli devant à terme être déployée sur 20 à 30 postes dont
certains à l'étranger...
- Est-ce à votre avis normale que la même dll pointe dans une machine sur
"Microsoft ActiveX Data Objects 2.6 Library" et sur "Microsoft ActiveX Data
Objects 2.5 Library" dans une autre ?
Merci pour votre contribution
@+ Alain79
Bonjour,
Difficile de prévoir absolument tous les cas de figure possibles de
configuration d'une trentaine de postes...
Une solution possible, AMA, pour éviter les mauvaises surprises, est de
recourir
dans ton code au 'late binding' (création des objets à l'exécution) plutôt
qu'à
l''early binding' (intégration des objets à la compilation qui utilise la
référence à une librairie installée sur le poste).
Concrètement, plutôt que d'établir une référence sur ton poste à une
bibliothèque (qui ne sera pas forcément présente sur un autre dans la même
version), ce qui te permet de déclarer tes variables sous cette forme (par
exemple, pour un Recordset) :
Dim rs As New ADODB.Recordset
utilise ce genre de syntaxe :
Dim rs As Object
Set rs=CreateObject("ADODB.Recordset")
De cette manière, Excel utilisera la bibliothèque installée sur le poste
où le
code s'exécute. Risque d'erreur cependant si cette bibliothèque ne permet
pas
l'exécution du code demandé (version trop ancienne par exemple). Mais, si
c'est
critique pour toi, tu devrais pouvoir tester la version du poste et
demander une
mise à jour si version trop ancienne.
FS
--
Frédéric Sigonneau [MVP Excel - né un sans-culottide]
Gestions de temps, VBA pour Excel :
http://perso.wanadoo.fr/frederic.sigonneau
Si votre question sur Excel est urgente, évitez ma bal !
Dans le cadre d'une application VBA sous Excel 2000 sur poste W2000pro
SP4,
et afin de pouvoir mettre en oeuvre des connexions ADO j'ai intégré une
référence à
- "Microsoft ActiveX Data Objects 2.6 Library"
- C:Program FilesCommon FilesSystemADOmsado15.dll
Jusque la tout va bien...
Lors du déport de mon complément Excel (Addin) sur un autre poste
normalement également en Excel2000 W2000pro et SP4, deux problèmes se
sont
présentés :
- la référence "Microsoft ActiveX Data Objects 2.6 Library" n'était
pas
disponible
- la référence "Microsoft ActiveX Data Objects 2.5 Library" l'était
mais
pointait sur un fichier dll portant le même nom "msado15.dll" que celui
me
donnant "Microsoft ActiveX Data Objects 2.6 Library" sur le poste
d'origine... ! Par contre les dll pointant sur d'autres versions
antérieures
de "Microsoft ActiveX Data Objects Library", v2.3 et 2.4 en
l'occurrence
ne présentaient pas de défaut, elles portaient bien le même nom pour des
version identiques de "Microsoft ActiveX Data Objects Library".
Mes quelques questions...
- Qu'est-ce qui détermine les références disponibles sur un poste ? ou
autrement dit comment uniformiser différents postes au regard des
références
disponibles, l'appli devant à terme être déployée sur 20 à 30 postes
dont
certains à l'étranger...
- Est-ce à votre avis normale que la même dll pointe dans une machine
sur
"Microsoft ActiveX Data Objects 2.6 Library" et sur "Microsoft ActiveX
Data
Objects 2.5 Library" dans une autre ?
Merci pour votre contribution
@+ Alain79
Bonjour,
Difficile de prévoir absolument tous les cas de figure possibles de
configuration d'une trentaine de postes...
Une solution possible, AMA, pour éviter les mauvaises surprises, est de
recourir
dans ton code au 'late binding' (création des objets à l'exécution) plutôt
qu'à
l''early binding' (intégration des objets à la compilation qui utilise la
référence à une librairie installée sur le poste).
Concrètement, plutôt que d'établir une référence sur ton poste à une
bibliothèque (qui ne sera pas forcément présente sur un autre dans la même
version), ce qui te permet de déclarer tes variables sous cette forme (par
exemple, pour un Recordset) :
Dim rs As New ADODB.Recordset
utilise ce genre de syntaxe :
Dim rs As Object
Set rs=CreateObject("ADODB.Recordset")
De cette manière, Excel utilisera la bibliothèque installée sur le poste
où le
code s'exécute. Risque d'erreur cependant si cette bibliothèque ne permet
pas
l'exécution du code demandé (version trop ancienne par exemple). Mais, si
c'est
critique pour toi, tu devrais pouvoir tester la version du poste et
demander une
mise à jour si version trop ancienne.
FS
--
Frédéric Sigonneau [MVP Excel - né un sans-culottide]
Gestions de temps, VBA pour Excel :
http://perso.wanadoo.fr/frederic.sigonneau
Si votre question sur Excel est urgente, évitez ma bal !
Dans le cadre d'une application VBA sous Excel 2000 sur poste W2000pro
SP4,
et afin de pouvoir mettre en oeuvre des connexions ADO j'ai intégré une
référence à
- "Microsoft ActiveX Data Objects 2.6 Library"
- C:Program FilesCommon FilesSystemADOmsado15.dll
Jusque la tout va bien...
Lors du déport de mon complément Excel (Addin) sur un autre poste
normalement également en Excel2000 W2000pro et SP4, deux problèmes se
sont
présentés :
- la référence "Microsoft ActiveX Data Objects 2.6 Library" n'était
pas
disponible
- la référence "Microsoft ActiveX Data Objects 2.5 Library" l'était
mais
pointait sur un fichier dll portant le même nom "msado15.dll" que celui
me
donnant "Microsoft ActiveX Data Objects 2.6 Library" sur le poste
d'origine... ! Par contre les dll pointant sur d'autres versions
antérieures
de "Microsoft ActiveX Data Objects Library", v2.3 et 2.4 en
l'occurrence
ne présentaient pas de défaut, elles portaient bien le même nom pour des
version identiques de "Microsoft ActiveX Data Objects Library".
Mes quelques questions...
- Qu'est-ce qui détermine les références disponibles sur un poste ? ou
autrement dit comment uniformiser différents postes au regard des
références
disponibles, l'appli devant à terme être déployée sur 20 à 30 postes
dont
certains à l'étranger...
- Est-ce à votre avis normale que la même dll pointe dans une machine
sur
"Microsoft ActiveX Data Objects 2.6 Library" et sur "Microsoft ActiveX
Data
Objects 2.5 Library" dans une autre ?
Merci pour votre contribution
@+ Alain79
Bonjour,
Difficile de prévoir absolument tous les cas de figure possibles de
configuration d'une trentaine de postes...
Une solution possible, AMA, pour éviter les mauvaises surprises, est de
recourir
dans ton code au 'late binding' (création des objets à l'exécution) plutôt
qu'à
l''early binding' (intégration des objets à la compilation qui utilise la
référence à une librairie installée sur le poste).
Concrètement, plutôt que d'établir une référence sur ton poste à une
bibliothèque (qui ne sera pas forcément présente sur un autre dans la même
version), ce qui te permet de déclarer tes variables sous cette forme (par
exemple, pour un Recordset) :
Dim rs As New ADODB.Recordset
utilise ce genre de syntaxe :
Dim rs As Object
Set rs=CreateObject("ADODB.Recordset")
De cette manière, Excel utilisera la bibliothèque installée sur le poste
où le
code s'exécute. Risque d'erreur cependant si cette bibliothèque ne permet
pas
l'exécution du code demandé (version trop ancienne par exemple). Mais, si
c'est
critique pour toi, tu devrais pouvoir tester la version du poste et
demander une
mise à jour si version trop ancienne.
FS
--
Frédéric Sigonneau [MVP Excel - né un sans-culottide]
Gestions de temps, VBA pour Excel :
http://perso.wanadoo.fr/frederic.sigonneau
Si votre question sur Excel est urgente, évitez ma bal !
Dans le cadre d'une application VBA sous Excel 2000 sur poste W2000pro
SP4,
et afin de pouvoir mettre en oeuvre des connexions ADO j'ai intégré une
référence à
- "Microsoft ActiveX Data Objects 2.6 Library"
- C:Program FilesCommon FilesSystemADOmsado15.dll
Jusque la tout va bien...
Lors du déport de mon complément Excel (Addin) sur un autre poste
normalement également en Excel2000 W2000pro et SP4, deux problèmes se
sont
présentés :
- la référence "Microsoft ActiveX Data Objects 2.6 Library" n'était
pas
disponible
- la référence "Microsoft ActiveX Data Objects 2.5 Library" l'était
mais
pointait sur un fichier dll portant le même nom "msado15.dll" que celui
me
donnant "Microsoft ActiveX Data Objects 2.6 Library" sur le poste
d'origine... ! Par contre les dll pointant sur d'autres versions
antérieures
de "Microsoft ActiveX Data Objects Library", v2.3 et 2.4 en
l'occurrence
ne présentaient pas de défaut, elles portaient bien le même nom pour des
version identiques de "Microsoft ActiveX Data Objects Library".
Mes quelques questions...
- Qu'est-ce qui détermine les références disponibles sur un poste ? ou
autrement dit comment uniformiser différents postes au regard des
références
disponibles, l'appli devant à terme être déployée sur 20 à 30 postes
dont
certains à l'étranger...
- Est-ce à votre avis normale que la même dll pointe dans une machine
sur
"Microsoft ActiveX Data Objects 2.6 Library" et sur "Microsoft ActiveX
Data
Objects 2.5 Library" dans une autre ?
Merci pour votre contribution
@+ Alain79
- A quel moment et avec quel soft MS sont installés les contrôles
activeX
sur lesquels les références pointent - Ou autrement dit, si le
contrôle
ActiveX n'est pas présent sur un poste que doit'on faire pour le
récupérer ?
- Comment obtenirde l'aide sur l'utilisation de l'ADO au sein
d'Excel
si on la récupère, peut-on l'intégrer à l'aide standard de telle
sorte que
la soft key <F1> soit opérationel sur un mot clef ADO dans un module
de code
?
- Comment se fait-il que je puisse trouver deux dll de même nom ne
pointant
pas sur le même contrôle activeX - cela signifie -t'il que c'est un
peu le
bordel dans le monde des contrôle activeX... ?
- A quel moment et avec quel soft MS sont installés les contrôles
activeX
sur lesquels les références pointent - Ou autrement dit, si le
contrôle
ActiveX n'est pas présent sur un poste que doit'on faire pour le
récupérer ?
- Comment obtenirde l'aide sur l'utilisation de l'ADO au sein
d'Excel
si on la récupère, peut-on l'intégrer à l'aide standard de telle
sorte que
la soft key <F1> soit opérationel sur un mot clef ADO dans un module
de code
?
- Comment se fait-il que je puisse trouver deux dll de même nom ne
pointant
pas sur le même contrôle activeX - cela signifie -t'il que c'est un
peu le
bordel dans le monde des contrôle activeX... ?
- A quel moment et avec quel soft MS sont installés les contrôles
activeX
sur lesquels les références pointent - Ou autrement dit, si le
contrôle
ActiveX n'est pas présent sur un poste que doit'on faire pour le
récupérer ?
- Comment obtenirde l'aide sur l'utilisation de l'ADO au sein
d'Excel
si on la récupère, peut-on l'intégrer à l'aide standard de telle
sorte que
la soft key <F1> soit opérationel sur un mot clef ADO dans un module
de code
?
- Comment se fait-il que je puisse trouver deux dll de même nom ne
pointant
pas sur le même contrôle activeX - cela signifie -t'il que c'est un
peu le
bordel dans le monde des contrôle activeX... ?
Merci pour ton intervention, j'essaierai le Late Binding - Quelques
interrogations néanmoins...
- A quel moment et avec quel soft MS sont installés les contrôles activeX
sur lesquels les références pointent - Ou autrement dit, si le contrôle
ActiveX n'est pas présent sur un poste que doit'on faire pour le récupérer ?
Est-ce lié à l'installatio d'Excel lui même ou alors d'un autr composant ?
- Comment obtenirde l'aide sur l'utilisation de l'ADO au sein d'Excel, et
si on la récupère, peut-on l'intégrer à l'aide standard de telle sorte que
la soft key <F1> soit opérationel sur un mot clef ADO dans un module de code
- Comment se fait-il que je puisse trouver deux dll de même nom ne pointant
pas sur le même contrôle activeX - cela signifie -t'il que c'est un peu le
bordel dans le monde des contrôle activeX... ?
- Comment tester si un contrôle ActiveX est présent sur un poste ?
Merci encore et @+
Alain79
"Frédéric Sigonneau" wrote in message
news:Bonjour,
Difficile de prévoir absolument tous les cas de figure possibles de
configuration d'une trentaine de postes...
Une solution possible, AMA, pour éviter les mauvaises surprises, est de
recourirdans ton code au 'late binding' (création des objets à l'exécution) plutôt
qu'àl''early binding' (intégration des objets à la compilation qui utilise la
référence à une librairie installée sur le poste).
Concrètement, plutôt que d'établir une référence sur ton poste à une
bibliothèque (qui ne sera pas forcément présente sur un autre dans la même
version), ce qui te permet de déclarer tes variables sous cette forme (par
exemple, pour un Recordset) :
Dim rs As New ADODB.Recordset
utilise ce genre de syntaxe :
Dim rs As Object
Set rs=CreateObject("ADODB.Recordset")
De cette manière, Excel utilisera la bibliothèque installée sur le poste
où lecode s'exécute. Risque d'erreur cependant si cette bibliothèque ne permet
pasl'exécution du code demandé (version trop ancienne par exemple). Mais, si
c'estcritique pour toi, tu devrais pouvoir tester la version du poste et
demander unemise à jour si version trop ancienne.
FS
--
Frédéric Sigonneau [MVP Excel - né un sans-culottide]
Gestions de temps, VBA pour Excel :
http://perso.wanadoo.fr/frederic.sigonneau
Si votre question sur Excel est urgente, évitez ma bal !
Dans le cadre d'une application VBA sous Excel 2000 sur poste W2000pro
SP4,et afin de pouvoir mettre en oeuvre des connexions ADO j'ai intégré une
référence à
- "Microsoft ActiveX Data Objects 2.6 Library"
- C:Program FilesCommon FilesSystemADOmsado15.dll
Jusque la tout va bien...
Lors du déport de mon complément Excel (Addin) sur un autre poste
normalement également en Excel2000 W2000pro et SP4, deux problèmes se
sontprésentés :
- la référence "Microsoft ActiveX Data Objects 2.6 Library" n'était
pasdisponible
- la référence "Microsoft ActiveX Data Objects 2.5 Library" l'était
maispointait sur un fichier dll portant le même nom "msado15.dll" que celui
medonnant "Microsoft ActiveX Data Objects 2.6 Library" sur le poste
d'origine... ! Par contre les dll pointant sur d'autres versions
antérieuresde "Microsoft ActiveX Data Objects Library", v2.3 et 2.4 en
l'occurrencene présentaient pas de défaut, elles portaient bien le même nom pour des
version identiques de "Microsoft ActiveX Data Objects Library".
Mes quelques questions...
- Qu'est-ce qui détermine les références disponibles sur un poste ? ou
autrement dit comment uniformiser différents postes au regard des
référencesdisponibles, l'appli devant à terme être déployée sur 20 à 30 postes
dontcertains à l'étranger...
- Est-ce à votre avis normale que la même dll pointe dans une machine
sur"Microsoft ActiveX Data Objects 2.6 Library" et sur "Microsoft ActiveX
DataObjects 2.5 Library" dans une autre ?
Merci pour votre contribution
@+ Alain79
Merci pour ton intervention, j'essaierai le Late Binding - Quelques
interrogations néanmoins...
- A quel moment et avec quel soft MS sont installés les contrôles activeX
sur lesquels les références pointent - Ou autrement dit, si le contrôle
ActiveX n'est pas présent sur un poste que doit'on faire pour le récupérer ?
Est-ce lié à l'installatio d'Excel lui même ou alors d'un autr composant ?
- Comment obtenirde l'aide sur l'utilisation de l'ADO au sein d'Excel, et
si on la récupère, peut-on l'intégrer à l'aide standard de telle sorte que
la soft key <F1> soit opérationel sur un mot clef ADO dans un module de code
- Comment se fait-il que je puisse trouver deux dll de même nom ne pointant
pas sur le même contrôle activeX - cela signifie -t'il que c'est un peu le
bordel dans le monde des contrôle activeX... ?
- Comment tester si un contrôle ActiveX est présent sur un poste ?
Merci encore et @+
Alain79
"Frédéric Sigonneau" <frederic.sigonneau@wanadoo.fr> wrote in message
news:4001512F.4BBB80E9@wanadoo.fr...
Bonjour,
Difficile de prévoir absolument tous les cas de figure possibles de
configuration d'une trentaine de postes...
Une solution possible, AMA, pour éviter les mauvaises surprises, est de
recourir
dans ton code au 'late binding' (création des objets à l'exécution) plutôt
qu'à
l''early binding' (intégration des objets à la compilation qui utilise la
référence à une librairie installée sur le poste).
Concrètement, plutôt que d'établir une référence sur ton poste à une
bibliothèque (qui ne sera pas forcément présente sur un autre dans la même
version), ce qui te permet de déclarer tes variables sous cette forme (par
exemple, pour un Recordset) :
Dim rs As New ADODB.Recordset
utilise ce genre de syntaxe :
Dim rs As Object
Set rs=CreateObject("ADODB.Recordset")
De cette manière, Excel utilisera la bibliothèque installée sur le poste
où le
code s'exécute. Risque d'erreur cependant si cette bibliothèque ne permet
pas
l'exécution du code demandé (version trop ancienne par exemple). Mais, si
c'est
critique pour toi, tu devrais pouvoir tester la version du poste et
demander une
mise à jour si version trop ancienne.
FS
--
Frédéric Sigonneau [MVP Excel - né un sans-culottide]
Gestions de temps, VBA pour Excel :
http://perso.wanadoo.fr/frederic.sigonneau
Si votre question sur Excel est urgente, évitez ma bal !
Dans le cadre d'une application VBA sous Excel 2000 sur poste W2000pro
SP4,
et afin de pouvoir mettre en oeuvre des connexions ADO j'ai intégré une
référence à
- "Microsoft ActiveX Data Objects 2.6 Library"
- C:Program FilesCommon FilesSystemADOmsado15.dll
Jusque la tout va bien...
Lors du déport de mon complément Excel (Addin) sur un autre poste
normalement également en Excel2000 W2000pro et SP4, deux problèmes se
sont
présentés :
- la référence "Microsoft ActiveX Data Objects 2.6 Library" n'était
pas
disponible
- la référence "Microsoft ActiveX Data Objects 2.5 Library" l'était
mais
pointait sur un fichier dll portant le même nom "msado15.dll" que celui
me
donnant "Microsoft ActiveX Data Objects 2.6 Library" sur le poste
d'origine... ! Par contre les dll pointant sur d'autres versions
antérieures
de "Microsoft ActiveX Data Objects Library", v2.3 et 2.4 en
l'occurrence
ne présentaient pas de défaut, elles portaient bien le même nom pour des
version identiques de "Microsoft ActiveX Data Objects Library".
Mes quelques questions...
- Qu'est-ce qui détermine les références disponibles sur un poste ? ou
autrement dit comment uniformiser différents postes au regard des
références
disponibles, l'appli devant à terme être déployée sur 20 à 30 postes
dont
certains à l'étranger...
- Est-ce à votre avis normale que la même dll pointe dans une machine
sur
"Microsoft ActiveX Data Objects 2.6 Library" et sur "Microsoft ActiveX
Data
Objects 2.5 Library" dans une autre ?
Merci pour votre contribution
@+ Alain79
Merci pour ton intervention, j'essaierai le Late Binding - Quelques
interrogations néanmoins...
- A quel moment et avec quel soft MS sont installés les contrôles activeX
sur lesquels les références pointent - Ou autrement dit, si le contrôle
ActiveX n'est pas présent sur un poste que doit'on faire pour le récupérer ?
Est-ce lié à l'installatio d'Excel lui même ou alors d'un autr composant ?
- Comment obtenirde l'aide sur l'utilisation de l'ADO au sein d'Excel, et
si on la récupère, peut-on l'intégrer à l'aide standard de telle sorte que
la soft key <F1> soit opérationel sur un mot clef ADO dans un module de code
- Comment se fait-il que je puisse trouver deux dll de même nom ne pointant
pas sur le même contrôle activeX - cela signifie -t'il que c'est un peu le
bordel dans le monde des contrôle activeX... ?
- Comment tester si un contrôle ActiveX est présent sur un poste ?
Merci encore et @+
Alain79
"Frédéric Sigonneau" wrote in message
news:Bonjour,
Difficile de prévoir absolument tous les cas de figure possibles de
configuration d'une trentaine de postes...
Une solution possible, AMA, pour éviter les mauvaises surprises, est de
recourirdans ton code au 'late binding' (création des objets à l'exécution) plutôt
qu'àl''early binding' (intégration des objets à la compilation qui utilise la
référence à une librairie installée sur le poste).
Concrètement, plutôt que d'établir une référence sur ton poste à une
bibliothèque (qui ne sera pas forcément présente sur un autre dans la même
version), ce qui te permet de déclarer tes variables sous cette forme (par
exemple, pour un Recordset) :
Dim rs As New ADODB.Recordset
utilise ce genre de syntaxe :
Dim rs As Object
Set rs=CreateObject("ADODB.Recordset")
De cette manière, Excel utilisera la bibliothèque installée sur le poste
où lecode s'exécute. Risque d'erreur cependant si cette bibliothèque ne permet
pasl'exécution du code demandé (version trop ancienne par exemple). Mais, si
c'estcritique pour toi, tu devrais pouvoir tester la version du poste et
demander unemise à jour si version trop ancienne.
FS
--
Frédéric Sigonneau [MVP Excel - né un sans-culottide]
Gestions de temps, VBA pour Excel :
http://perso.wanadoo.fr/frederic.sigonneau
Si votre question sur Excel est urgente, évitez ma bal !
Dans le cadre d'une application VBA sous Excel 2000 sur poste W2000pro
SP4,et afin de pouvoir mettre en oeuvre des connexions ADO j'ai intégré une
référence à
- "Microsoft ActiveX Data Objects 2.6 Library"
- C:Program FilesCommon FilesSystemADOmsado15.dll
Jusque la tout va bien...
Lors du déport de mon complément Excel (Addin) sur un autre poste
normalement également en Excel2000 W2000pro et SP4, deux problèmes se
sontprésentés :
- la référence "Microsoft ActiveX Data Objects 2.6 Library" n'était
pasdisponible
- la référence "Microsoft ActiveX Data Objects 2.5 Library" l'était
maispointait sur un fichier dll portant le même nom "msado15.dll" que celui
medonnant "Microsoft ActiveX Data Objects 2.6 Library" sur le poste
d'origine... ! Par contre les dll pointant sur d'autres versions
antérieuresde "Microsoft ActiveX Data Objects Library", v2.3 et 2.4 en
l'occurrencene présentaient pas de défaut, elles portaient bien le même nom pour des
version identiques de "Microsoft ActiveX Data Objects Library".
Mes quelques questions...
- Qu'est-ce qui détermine les références disponibles sur un poste ? ou
autrement dit comment uniformiser différents postes au regard des
référencesdisponibles, l'appli devant à terme être déployée sur 20 à 30 postes
dontcertains à l'étranger...
- Est-ce à votre avis normale que la même dll pointe dans une machine
sur"Microsoft ActiveX Data Objects 2.6 Library" et sur "Microsoft ActiveX
DataObjects 2.5 Library" dans une autre ?
Merci pour votre contribution
@+ Alain79