VBA er Références non valides

Résolu
Signaler
Messages postés
3877
Date d'inscription
mardi 19 mars 2002
Statut
Membre
Dernière intervention
23 août 2018
-
Messages postés
3877
Date d'inscription
mardi 19 mars 2002
Statut
Membre
Dernière intervention
23 août 2018
-
Bonjour les pros,

Jusqu'à présent, mes programmes étaient utilisés par mon équipe, avec les mêmes versions Windows et Office. À partir de maintenant, je vais devoir distribuer des applications sous différentes versions de Windows (2000 et XP) et Office (2000, 2003 et éventuellement XP)

Types de références à problème
- Office
- Outlook
- Microsoft Scripting Runtime (le foutu scrrun.dll)

J'ai fait quelques recherches et il semble qu'on puisse modifier les références en passant par
ThisWorkbook.VBProject.References

Le problème, c'est que je n'arrive pas à intercepter le programme avant le message d'erreur...
J'ai essayé différents événements dans ThisWorkbook dont, bien sûr, Workbook_Open
Rien à faire pour l'instant ...

Est-ce que je dois enlever toutes les références à risque, cochées manuellement dans l'IDE, et les créer/activer seulement une fois que le classeur est ouvert ?

Toute piste est la bienvenue

Merci !

MPi

4 réponses

Messages postés
14008
Date d'inscription
samedi 29 décembre 2001
Statut
Modérateur
Dernière intervention
28 août 2015
81
Salut
Concernant le "foutu" scrrun.dll, une technique consiste à déclarer l'objet FileSystemObjet (FSO) sans utiliser de référence à la DLL, de cette manière, il prend la version disponible au moment du run :
Au lieu de :
   Dim monFSO As New FileSystemObject
   Set monFSO = New FileSystemObject
Utiliser :
   Dim monFSO As Object
   Set monFSO = CreateObject("Scripting.FileSystemObject")

Inconvénient :
Puisque l'objet n'est pas référencé dans le projet, on ne peut pas profiter de l'affichage des propriétés et méthodes quand, en mode IDE, on tape le point derrière l'objet monFSO.

Pour le reste, je ne sais pas, désolé.

Vala
Jack, MVP VB
NB : Je ne répondrai pas aux messages privés

Champion du monde de boule de cristal - 2005
Le savoir est la seule matière qui s'accroit quand on la partage
Messages postés
3877
Date d'inscription
mardi 19 mars 2002
Statut
Membre
Dernière intervention
23 août 2018
19
Merci Jack,

En fait je n'utilise pas vraiment le FileSystemObject, mais plutôt une fonction d'Excel
Application.FileSearch
qui se sert, semble-t-il, de ce FileSystemObject ou d'une partie de cette DLL.

Quoiqu'il en soit, je vais faire un test lundi et quelque chose me dit que ça devrait fonctionner en utilisant ta méthode ... à voir ...
Sinon, je procéderai différemment avec une procédure maison.

Je pense que je ne suis pas au bout de mes peines.
Je viens de remarquer que les macros complémentaires "Utilitaire d'Analyse" ne sont pas les mêmes en français et en anglais. Les formules ne se traduisent pas automatiquement d'un langage à l'autre.
Des heures de plaisir en vue...

MPi
Messages postés
18
Date d'inscription
samedi 2 juin 2007
Statut
Membre
Dernière intervention
22 août 2008

Bonsoir,
Application.FileSearch ne réclame pas la référence FileSystemObject :

Sub ListeFichiers()
Dim f
With Application.FileSearch
    .LookIn = "c:\tmp"
    .FileType = msoFileTypeExcelWorkbooks
    .Execute
End With

For Each f In Application.FileSearch.FoundFiles
 Debug.Print f
Next
End Sub

Satanas09 ..... Sapristi, saprista, souris grise et face de rat
Messages postés
3877
Date d'inscription
mardi 19 mars 2002
Statut
Membre
Dernière intervention
23 août 2018
19
Salut Satanas,

En fait, je supposais que ça devait être la DLL scrrun ... mauvaise supposition, je présume.

Pour expliquer un peu, une nouvelle personne s'est jointe à l'équipe et son PC est équipé de Win XP et Office 2003. Les autres sont sous Win 2000 et Oficce 2003.

Lorsque j'exécute le même code que tu proposes (et que j'utilise depuis quelques années), aucune erreur, mais
Application.FileSearch.FoundFiles = 0
même si je vois physiquement plusieurs fichiers dans le répertoire où le code vient de les copier (C:\Temp). Bien sûr, le reste du programme basé là-dessus ne fonctionne plus.

Si je vais dans les propriétés du répertoire, il est coché "lecture seule" en grisé. Et il m'est impossible de changer cette propriété... elle revient toujours cochée en grisé.

À l'aide du technicien qui a installé le PC, on en est venu à se dire qu'il s'agissait du Scripting Runtime... J'ai donc créé une référence directe dans mon programme et ç'a réglé le problème du coup (?!?). Est-ce un hasard ? je n'en sais vraiment rien... Il me reste à faire encore des tests...

Quand je dis foutu DLL, c'est qu'on a déjà eu des problèmes d'installation d'un logiciel VB utilisant cette DLL, il y a plusieurs années. Créé sous Win98, il n'était pas compatible avec NT...

Jack,
j'ai pu faire un test sur mon autre PC avec Outlook XP et le CreateObject règle le problème d'incompatibilité de versions. En fait je n'aurai qu'à éliminer toute référence superflue, autre que celles de base, et les créer directement dans le code à l'ouverture ou sur demande... Je commence à mieux respirer

Merci à vous deux
(je vais attendre encore un peu avant de cocher Accepter...)

MPi