VBA er Références non valides

Résolu
cs_MPi Messages postés 3877 Date d'inscription mardi 19 mars 2002 Statut Membre Dernière intervention 17 août 2018 - 2 juin 2007 à 17:24
cs_MPi Messages postés 3877 Date d'inscription mardi 19 mars 2002 Statut Membre Dernière intervention 17 août 2018 - 3 juin 2007 à 17:17
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

cs_Jack Messages postés 14006 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 79
2 juin 2007 à 20:08
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
3
cs_MPi Messages postés 3877 Date d'inscription mardi 19 mars 2002 Statut Membre Dernière intervention 17 août 2018 23
2 juin 2007 à 21:06
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
0
Satanas09 Messages postés 18 Date d'inscription samedi 2 juin 2007 Statut Membre Dernière intervention 22 août 2008
2 juin 2007 à 22:24
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
0
cs_MPi Messages postés 3877 Date d'inscription mardi 19 mars 2002 Statut Membre Dernière intervention 17 août 2018 23
3 juin 2007 à 17:17
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
0
Rejoignez-nous