Discussion :

[vodiem]

il y a qd même plus simple, plus rapide et plus sur que le code proposé dans la faq ici
là j'avais 10s sous la main:

Code :

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

1
2
3
Function existFile(ByVal fichier As String) As Boolean
existFile = Dir(fichier, vbNormal Or vbReadOnly Or vbHidden Or vbArchive) <> ""
End Function

d'ailleurs celui proposé ne fait pas de récursivité dans les sous sous... dossiers, seul les fichiers des sous dossiers de premier niveau sont explorés.
et je parle pas du fait qu'il ne parcours même pas les fichiers du dossier demandé mais uniquement ceux de ses sous dossiers de premier niveau!
et encore moins du "end" au lieu de "Exit For" qui annule le résultat si le fichier est trouvé!
pas bô tout ca...

[marot_r]

Cette syntaxe est plus légère mais attention c'est du vieux stock :o) (ça vient du Gwbasic des années 1990). Il se peut quelle ne fonctionne pas correctement dans certains environnements plus modernes. Pour le moment je n'ai jamais expérimenté de problème avec mais il est bon de connaître l'autre syntaxe.

A+

[vodiem]

traite moi de ringard mais c'est dans les vieilles casseroles qu'on fait les meilleurs soupes. :p
les batchs n'ont pas encore disparu que je sache et cela marche toujours alors que les codes plus récents ne fonctionnent pas toujours.

mais si tu veux on peut faire plus long en plus récent:

Code :

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

1
2
3
4
5
Function existeFileFSO(ByVal fichier As String) As Boolean
Set fs = CreateObject("Scripting.FileSystemObject")
existeFileFSO = fs.FileExists(fichier)
Set fs = Nothing
End Function

ou encore plus récent (?):

Code :

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

1
2
3
4
5
6
7
8
Declare Function SearchPath Lib "kernel32" Alias "SearchPathA" (ByVal lpPath As String, ByVal lpFileName As String, ByVal lpExtension As String, ByVal nBufferLength As Long, ByVal lpBuffer As String, ByVal lpFilePart As String) As Long
 
Function existeFileSearchPath(ByVal chemin, fichier As String) As Boolean
    'Requires Windows Vista, Windows XP, or Windows 2000 Professional.
    Dim ResultFileName As String
    Dim pFilePart As Long
    existeFileSearchPath = SearchPath(chemin, fichier, vbNullString, 1, ResultFileName, pFilePart) > 0
End Function

et je ne doute pas que l'on trouve d'autres façons de faire avec des "Open" ou à partir d'autres objets.
je voulais simplement faire court et je ne doute pas que cela marchera encore avant ma mort: je le jure sur ma tête.

[marot_r]

traite moi de ringard mais c'est dans les vieilles casseroles qu'on fait les meilleurs soupes. :p

Que neni messire, j'utilise généralement Dir et Open que je trouve beaucoup plus clair et surtout que je connais mieux (c'est pas pour rien que je peux dire de quand elles datent).

Mais par exemple marchent-elles si tu veux faire un test sur fichier situé sur un serveur distant sans mapping disque ?

Merci pour tes syntaxes plus récentes, je vais me les imprimer.

A+

[vodiem]

oui, je viens de faire les tests sur un serveur distant sans mapping disque: les trois fonctions... fonctionnent.

mais j'irais pas pousser à faire une fonction autorisant d'une session avec restriction à connaitre l'existance d'un fichier sur un dossier demandant certains pouvoirs par login et mot de passe...

[LedZeppII]

Le nom vieillot faisant référence à la commade du même nom sous DOS (et CMD) et sa syntaxe simplissime sont à mon avis trompeurs
Le Dir de VBA n'est pas le Dir de l'interpréteur de commande CMD.
A mon avis la fonction Dir de VBA utilise l'API Windows et évolue au fil des changements de Windows.
Sinon on ne pourrait l'utiliser qu'avec des noms de fichiers courts (8+3).

La conclusion c'est que Dir de VBA et FileExists de Scripting.FileSystemObject permettent de tester l'existance d'un fichier plus simplement que la solution proposée dans la faq.

Vodiem : As-tu contacté le responsable de la faq par MP pour signaler ce problème ?

A+

[vodiem]

salut ledZeepII,

Le Dir de VBA n'est pas le Dir de l'interpréteur de commande CMD.
A mon avis la fonction Dir de VBA utilise l'API Windows et évolue au fil des changements de Windows.
Sinon on ne pourrait l'utiliser qu'avec des noms de fichiers courts (8+3).

ce n'est pas exacte pour le dir du dos qui a dès le début intégré les noms de fichiers long dès la première version de win qui l'a géré.
mais tu as surement raison, pour ce qui est de l'évolution de la fonction dir de vba qui comme sous dos évolue (sinon en mode console on pourrait même pas adresser les nouvelles limitations de disque ce qui poserait un sérieux problème de maintenance).
donc de là à dire que les commandes dos sont différents de ceux de windows (vba & Co.), je doute: ils doivent tous finir au même driver.
Je dirais donc vieux mais bien conservé, comme nous...

ps: pour la faq, non. d'ailleurs je n'ai pas trouvé d'endroit sur dvp (j'ai pas beaucoup cherché non plus) où l'on retrouve un organigramme des responsables. il serait bien d'ailleurs d'afficher les responsables de forum pour chaque forum.

[Invité]

Bonjour

Je vais signaler ceci au responsable de la FAQ Access, il est trés pris cette semaine, mais il sera au courant.



Starec

[LedZeppII]

Bonsoir,

En tout début de la faq il y a un lien vers le responsable : http://www.developpez.net/forums/member.php?u=47206

ce n'est pas exacte pour le dir du dos qui a dès le début intégré les noms de fichiers long dès la première version de win qui l'a géré

Effectivement je vois que j'ai mal formulé ce que je voulais dire.
Comme marot_r parlait d'une technologies des années 90 je pensais plus à un DOS 6.
Mais j'ai parlé de CMD, ce qui ne colle pas.

Est-ce que les utilisateurs d'Office pour Mac s'inquiètent d'utiliser une fonction s'appelant Dir dans VBA ?
Si oui, il seront embêtés pour trouver du "Scripting.FileSystemObject"
Ce que je veux dire, c'est que le code source de la fonction VBA Dir est certainement adapté au mieux pour la plateforme où elle va s'exécuter.
Pourquoi ils s'embêteraient à maintenir une fonction compatible DOS alors qu'Office ne tourne pas sous DOS ?

A+

[Lou Pitchoun]

ps: pour la faq, non. d'ailleurs je n'ai pas trouvé d'endroit sur dvp (j'ai pas beaucoup cherché non plus) où l'on retrouve un organigramme des responsables. il serait bien d'ailleurs d'afficher les responsables de forum pour chaque forum.

La création d'une page team Office est en cours.