[Fait]Comment vérifier l'existence d'un fichier (FSO) [FAQ]

[Jean Luc Ravenne]

Cette fonction sert dans la programmation "médecine chinoise".. Anticiper c'est mieux que guérir, surtout en VBA ou l'utilisateur peut facilement se retrouver sur le code en cas de fichier non trouvé.. Cette fonction est plus simple et plus facile que la gestion programmée de l'erreur..

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
' Vérifier l'existence d'un fichier(par ex avant de l'ouvrir..)
Function VerifierExistenceFichier(ByVal Mondossier, ByVal MonFichier) As Boolean
    Dim ObjFSO, ListRepertoires, ListSousRep, ListFichiers, MonRep, LesReps, MonFich, LesFichs
    Set ObjFSO = CreateObject("Scripting.FileSystemObject")
    VerifierExistenceFichier = False
    Set ListRepertoires = ObjFSO.GetFolder(Mondossier)
    Set ListSousRep = ListRepertoires.SubFolders
    For Each MonRep In ListSousRep
            Set ListFichiers = MonRep.Files
            For Each MonFich In ListFichiers
                If MonFich.Name = MonFichier Then
                    'trouvé
                    VerifierExistenceFichier = True
                    End
                End If
            Next MonFich
    Next MonRep
End Function

[philben]

bonjour,

j'ai l'impression de voir de plus en plus de code <Late Binding> sur le site :

Code :

1
2
CreateObject("Scripting.FileSystemObject")

Pour ma culture, je me demande quels sont les intérêts de la liaison tardive en particulier ici ?

merci,

Philippe

[AlainTech]

L'intérêt, c'est de ne pas devoir ajouter de référence dans le projet.

[philben]

la liaison est tardive, les erreurs le seront aussi...
philippe

[mout1234]

Envoyé par AlainTech

L'intérêt, c'est de ne pas devoir ajouter de référence dans le projet.

et donc que l'application continue de fonctionner (sauf le code qui utilise l'objet) si l'application référencée est manquante.

Pour ma part, je fais toujours du Late Binding avec des objets Word ou Excel par exemple, si je dois déployer une appli sur plusieurs postes sans être sûr qu'ils ont tous les produits attendus...

[philben]

bonjour Mout1234 ,

et donc que l'application continue de fonctionner (sauf le code qui utilise l'objet) si l'application référencée est manquante

Je suis surpris que l'on puisse préférer une erreur a déclenchement aléatoire dans le temps plutot qu'un beau bouquet final (ou plutot initial !) d'erreur ?

De plus :
* il faut se souvenir des références tardives utilisées pour vérifier quelles sont bien sur le poste;
* le développement n'est pas facilité par vbe avec les liaisons tardives
* la perf est semble t'il inférieure par rapport au early binding
* Je préfère contrôler les erreurs qui peuvent l'être, y'a suffisamment d'erreurs externes et internes potentielles !

C'est un effet de mode ou suis-je totalement rétrograde ou j'ai rien compris aux avantages !

Philippe

[philben]

bonjour,

En y réfléchissant, j'ai trouvé un avantage.
De mémoire, si un poste possède une version antérieure de la référence X, Access lève une erreur dans le cas d'une liaison précoce mais il n'en lévera pas dans le cas d'une liaison tardive (hors problème éventuel de méthode ou de propriété manquante dans la version antérieure).

Si c'est bien ça, je reconnais que c'est un intérêt non négligeable.

Philippe

[AlainTech]

Le plus grand intérêt, à mes yeux, est la référence aux librairies Office qui ont besoin de la version quand on les définit.

Astuce:
Développer en liaison précoce et déployer en liaison tardive.
De cette manière, on garde tout l'intérêt de l'Intellisense et on ne se heurte pas au problème des références manquantes.

[Philippe JOCHMANS]

Envoyé par AlainTech

Le plus grand intérêt, à mes yeux, est la référence aux librairies Office qui ont besoin de la version quand on les définit.

Astuce:
Développer en liaison précoce et déployer en liaison tardive.
De cette manière, on garde tout l'intérêt de l'Intellisense et on ne se heurte pas au problème des références manquantes.

+ 1

Je me suis fait avoir plusieurs fois, depuis je travaille de cette manière.

Starec

[kgb1917]

Bonjour,

Je vais bientôt faire un déploiement de ma base (dorsale/frontale) et j’aimerai savoir si vous pouviez expliquer un peu plus concrètement ou m’orienter vers des tutos (pas celui sur le déploiement, je l’ai lu) ou lectures sur le sujet FSO ?
Comment se matérialise

Développer en liaison précoce et déployer en liaison tardive

?

Merci par avance

[philben]

bonjour,

merci à AlainTech pour la précision.

Je retiens l'intérêt du Late Binding pour les références Office (ce que fait Mout1234 d'ailleurs) et l'astuce pour l'Intellisense.
Pour les autres références comme <scripting runtime> je ne vois encore aucun avantage, au contraire.

kgb1917 a écrit :

vers des tutos (pas celui sur le déploiement, je l’ai lu) ou lectures sur le sujet FSO ?

Un lien qui te permettra d'avoir toutes les bases pour manipuler FSO :
1) Tuto de Warin (Tofalu)
http://warin.developpez.com/access/fichiers/

Comment développer en liaison précoce (early binding) pour profiter l'Intellisense de VBA puis finir en late binding ?

Exemple (si j'ai bien compris )
Le premier code en early binding avec référencement de la référence <Microsoft Scripting Runtime> :

Code :

1
2
3
4
5
 
Dim oSFS As Scripting.FileSystemObject
Dim oSD As Scripting.Drive
Set oSFS = New Scripting.FileSystemObject
...

Le même en Late Binding c'est à dire les déclarations à la référence sont masqué au compilateur et elles se feront dynamiquement lors d'un appel (en gros !) :

Code :

1
2
3
4
Set oSFS As Object, oSD As Object
Set oSFS = CreateObject("Scripting.FileSystemObject")
...

Donc à la fin du développement on transforme le code early binding en late binding. Pour voir si on a rien oublié, désactiver la référence <scripting runtime>, puis faire une compilation pour lever un éventuel oubli d'une liaison précoce.

Philippe

[mout1234]

Bonsoir Philben et les autres,

Envoyé par philben

Je suis surpris que l'on puisse préférer une erreur a déclenchement aléatoire dans le temps plutot qu'un beau bouquet final (ou plutot initial !) d'erreur ?

Soyons plus clair:
- Pendant la phase de dev, je déclare les objets en Early Binding et bénéficie ainsi de l'intellisense.
- si je suis sur que tous les utilisateurs disposent du logiciel attendu (et de la même version...), je préfère bien sur garder une déclaration précoce.
- mais il y des cas où on est sur n'ont pas que tous les utilisateurs n'auront pas forcément le produit. Pour développer la fonctionnalité pour certains utilisateurs concernés sans perturber les autres... la déclaration tardive est bien utile.