Discussion :

[Janny]

Bonjour à tous !!!

J'ai un gros souci ! Mon applciation est terminée et elle utilise la référence Microsoft Access 11.0 Object Library. Celle ci existe sur les postes de l'entreprise mais n'est pas activée !
Je souhaiterai savoir s'il est possible de les activer dynamiquement (le chemin étant, dans C:\ Program Files\Microsoft Office\OFFICE11\MSACC.OLB)


Je vous remercie vraiment par avance !!

[Gaetch]

Mais une fois qu'un exécutable est généré, y'a plus besoin des bibliothèques qui t'ont servi à le faire, si ?

[Vld44]

ben si lol

[SfJ5Rpw8]

et c'est quoi que tu appelle activée..? ou pas sur un poste ..?

[Gaetch]

Vld44 >> Ben enfin ça veut dire que si tu fais un programme avec VB en utilisant certaines bibliothèques, ceux qui ont pas les bibliothèques sur leur PC peuvent pas l'exécuter ?

[Janny]

Bonjour !

En fait, le fichier MSACC.OLB existe squr les postes donc pour cela, pas de soucis. Le problème c'est que je ne peux pas vérifier si cette référence est par défaut coché car ces postes n'ont pas VB6.

J'ai mis des messages partout dans mon programme pour savoir à quelle ligne exactement ça plante, et c'est sur le "BuildCriteria". Cette commande necéssite la référence MSACC.OLB c'est à dire Microsoft Access 11.0 Object Library.

Nous avons toutes les raisons de penser que cette référence n'est pas activé sur ce poste.

Merci d'avance !!!

[SfJ5Rpw8]

ce fichier : MSACC.OLB ... il est au même endroit sur tous les postes..? comment à t'il été installé..?

[Janny]

Sur chaque poste au même endroit oui :
C:\Program Files\Microsoft Office\OFFICE11\MSACC.OLB

par contre comment il a été installé..... j'en sais rien

[Vld44]

Vld44 >> Ben enfin ça veut dire que si tu fais un programme avec VB en utilisant certaines bibliothèques, ceux qui ont pas les bibliothèques sur leur PC peuvent pas l'exécuter ?

Exactement.

Cela amène l'erreur suivante :

(je vais l'écrire de façon exhaustive pour l'outil de recherche du forum, car la question revient souvent)

Erreur d'exécution 429 : Le composant ActiveX ne peut pas créer l'objet

Run-Time Error 429: ActiveX component can't create object

D'où la livraison des DLLs dans le package de l'application quand c'est nécessaire.

Après y'a un problème connexe, c'est la version des DLLs existantes sur les PC clients et celle des DLLs utilisées pour compiler l'appli ... Mais c'est une autre histoire

[Janny]

J'ai trouvé un bout de code pour ajouter une référence en VBA excel, mais je n'arrive pas à trouver la syntaxe pour vb6 :

Code :

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

1
2
3
4
'Ajoute la référence Outlook pour OfficeXP
Dim x As String
x = "C:\Program Files\Microsoft Office\Office10\MSOUTL.OLB"
ThisWorkbook.VBProject.References.AddFromFile x

Quelqu'un a t'il une solution, j'ai déjà essayé plein de trucs....

[Vld44]

ben sans le message d'erreur, on peut rien pour toi.

[Janny]

l'erreur est :
"AddBranch_v1 : 513: AddBranch_priv_v1 : 513: AddBranch_priv_v1 : 429: ActiveX component can't create object"

la gestion d'erreur est faite dans une de mes fonction, il faut retenir :
"429: ActiveX component can't create object"

[Janny]

donc je pense que le problème vient bien de la référence manquante...

[Gaetch]

Ben alors s'il fait un package avec les librairies qu'il utilise ça sera bon non ?

Vld44 >> Moi je pensais que quand ça compilait ça incorporait les dll dans le code :/ *à l'ouest*

[Janny]

J'ai pas tout suivi
Comment ça un package?

[Vld44]

En fait, c'est compliqué COM

De deux choses l'une.

1) le soft de janny utilise des DLLs propriétaires, conçues pour l'occasion.
=> Il faut faire un installeur qui intègre ces DLL avec l'application, qui les enregistre dans la base de registre au moment de l'install
Facile.

2) le soft de janny utilise des DLLs publiques, telles que celles d'office, et là c'est la galère si ses postes clients n'utilisent pas les mêmes versions d'office ..

En fait, si c'est le cas numéro 2, l'application doit avoir été compilée en utilisant les mêmes versions des DLLs que celles du poste de développement.

Normalement, on de devrait pas avoir à faire ça. Une DLL est sensée respecter le principe de compatibilité descendante, stipulant que toute nouvelle version ne doit pas empêcher de fonctionner les applis exploitant les plus anciennes ... Mais bon dans la pratique c'est assez mitigé, on trouve autant de softs qui respectent ça que le contraire.

Janny il faut vraiment que tu identifies tes DLLs, à partir du poste de DEV.
Il faut ensuite faire une comparaison entre celles utilisées pour la compilation et celles des postes clients pour trouver la faille.

Note : quand je dis DLL, faut comprendre composant Activex soit DLL activex, EXE activex ou contrôle OCX

[Gaetch]

Janny >> Ben un package d'installation qui contient les librairies nécessaires. Enfin je sais pas comment on fait ^^

[Gaetch]

Vld44 >> Mais même si c'est des librairies publiques, s'il les intégre quand même ça fait quoi ? Où alors s'il fait ça, elles écraseront celles qu'il y a déjà sur le poste (et donc ça posera le pb de compatibilité descendante tout ça) ?

[Janny]

Merci Vld44

j'ai une procédure pour activer les .dll, .ocx... donc pour cela pas de souci !
Le problème c'est que la référence qu'il me faut est .olb !!!!!!!!!!!
et là ça ne marche plus !!

[Phifi]

Les .olb sont des composants Office. Tu dois les intégrer à ton package mais les postes déployés doivent obligatoirement avoir une version au moins aussi récente de l'application Office dont tu intégres le composant.

Ex : tu insères MSOUTL.OLB version 10 dans ton empaquetage (Offce 2002 il me semble), les postes déployés doivent posséder une version d'Office 2002 ou supérieur (compatibilité oblige) pour fonctionner.