cs_MPi
Messages postés3877Date d'inscriptionmardi 19 mars 2002StatutMembreDernière intervention17 août 2018
-
2 juin 2007 à 17:24
cs_MPi
Messages postés3877Date d'inscriptionmardi 19 mars 2002StatutMembreDernière intervention17 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 ?
cs_Jack
Messages postés14006Date d'inscriptionsamedi 29 décembre 2001StatutModérateurDernière intervention28 août 201579 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
cs_MPi
Messages postés3877Date d'inscriptionmardi 19 mars 2002StatutMembreDernière intervention17 août 201823 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...
cs_MPi
Messages postés3877Date d'inscriptionmardi 19 mars 2002StatutMembreDernière intervention17 août 201823 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...)