Basic ou fso - Intérêt d'une méthode sur une autre ? Pour faire bien ?

[ouskel'n'or]

Ancien utilisateur de divers basics j'aimerais savoir, avant d'être perclus de rhumatismes et de ne plus pouvoir torturer mon clavier, l'intérêt qu'il y a à utiliser GetFolder plutôt que Dir pour obtenir la liste des fichiers d'un répertoire.
Est-ce une question de temps d'exécution (???) d'occupation de l'UC ? de la mémoire ? De compatibilité entre les applis ? Ou c'est simplement pour faire bien ?

Sub Macro1(Chemin as string)
Dim fso As New FileSystemObject
Dim Fich As File
Dim Rep As Folder
Dim CL As Variant
    Set Rep = fso.GetFolder(Chemin)
    For Each Fich In Rep.Files
        CL = Chemin & Fich.Name
        If fso.GetExtensionName(CL) = "xls" Then _
           Workbooks.Open CL
           DoEvents
    Next
    Set Rep = Nothing
End Sub

Sub Macro2(chemin as string)
Dim NomFich() As Variant
On Error Resume Next
    NomFich = Dir(chemin, vbNormal)
    If Err = 5 Then Exit Sub
    Do While NomFich <> ""
        Workbooks.Open Chemin + NomLu
        DoEvents
        NomFich = Dir
    Loop
On Error GoTo 0
End Sub

Il en va de même pour l'ouverture d'un fichier Texte :

    Open "c:\Text.txt" For Input As #1
    ...

    ...
    Set fso = CreateObject("Scripting.FileSystemObject")
    Set File = fso.GetFile("C:\Text.txt")
    Set Txt = File.OpenAsTextStream(ForReading)
    ...

[ucfoutu]

Envoyé par ouskel'n'or

Ancien utilisateur de divers basics j'aimerais savoir, avant d'être perclus de rhumatismes et de ne plus pouvoir torturer mon clavier, l'intérêt qu'il y a à utiliser GetFolder plutôt que Dir pour obtenir la liste des fichiers d'un répertoire.
Est-ce une question de temps d'exécution (???) d'occupation de l'UC ? de la mémoire ? De compatibilité entre les applis ? Ou c'est simplement pour faire bien ?

Bonjour, Ousk...

La question que tu as posée là aurait dû l'être dans le sens inverse, à savoir :

Quel est l'intérêt qu'il y aurait à utiliser Dir, plutôt que le GetFolder de FSO et, de manière plus générale, d'utiliser les fonctions de VB plutôt que FSO ...

Réponse claire : En utilisant VB, tu ne charges pas inutilement ton appli par ce lourdaud de FSO ===>> tu gagnes ainsi en tout, y compris en vitesse d'exécution... et tu restes indépendant ...

Je l'ai dit mille et une fois : qu'on me pende le jour où l'une de mes applis se servira de FSO !

[ouskel'n'or]

Merci ucfoutu, du coup j'ai modifié le sujet de la discussion

Edit
Comme je ne suis pas sectaire, j'avoue que j'utilise fso pour lister les sous-répertoires d'un répertoire donné plutôt qu'un dir vbdirectory dans le dir vbdirectory
Tu m'en veux pas ?

[ucfoutu]

Ouais...

Tu sais quoi ?

1) la plupart du temps, il faut très peu de code VB pour faire ce que fait FSO
2) lorsque FSO apporte un "confort" au développeur, il n'apporte en réalité qu'une impression de confort, pas un vrai confort, et "soumet" à son joug.
Il vaut bien mieux, dans certains cas, avoir un module en VB (prenant dans certains cas de figure - copies de répertoires, etc... - plus de lignes de code, mais garantissant l'indépendance de ton appli, tournant plus agilement et ... permettant des "finesses" personnelles...)
3) tu veux tout savoir ? ... je n'utilise même pas le contrôle CommonDialog (ce n'est pas du FSO, mais c'est pour que tu comprennes...) ! je lui préfère d'autres méthodes, en fonction de mes besoins (Dir, etc... et même, s'il me faut réellement ouvrir une boîte Windows, l'utilisation directe de l'Api de Windows...).

[DarkVader]

Bonjour,
On peut toujours chercher à réinventer la roue et vouloir s'affranchir de tout -
en ce cas, pourquoi utiliser VB dont la force est principalement la vitesse de développement du fait dela richesse des librairies COM ?
Autant utiliser un autre langage qui soit plus portable et surtout qui ne soit pas dépendant lui-même de librairies (je parle de VB6).
La seule certitude que j'ai vis à vis de cette philosophie d'un refus systématique
c'est qu'on s'oriente vers une perte de temps et pire vers une usine à gaz.

Que tu substitues aux méthodes les plus lourdes de certaines librairies des routines personnelles
(remplacement de la lecture écriture de fichier pour fso par exemple) a un sens -
vouloir s'en affranchir totalement n'en a pas.

De plus, concernant scrrun, fso n'est qu'une partie des outils fournis car même si le Dictionary ou l'Encoder sont méconnus,
ils ont l'avantage d'exister là où il n'y a pas grand'chose en remplacement.


Personnellement, je ne pense pas qu'il y ait de solution prédéfinie :
le choix dépend de l'emplacement dans le code, du nombre d'appel etc., en somme seul une évaluation (avec gettickcount par exemple)
permettra de savoir quel choix opérer.

[ucfoutu]

Bonjour, DarkVader,

Je t'ai lu jusqu'au bout... et ne change rien à mes habitudes...
Je ne me contente jamais de "chronométrer" mes applis ...
Je les teste systématiquement sur une machine (âgée mais soignée) que j'ai "underclokée" à cette fin de tests

Quant au reste, l'arrivée de Vista aujourd'hui, de je ne sais trop quoi demain, me fait littéralement "fuir" les "conforts" en tous genre.

FSO, enfin, n'est pas VB ...

[philben]

bonjour,

je crois que ucfoutu a une vision très réductrice des possibilités de fso qui permet de nombreuses opérations que l'on ne pourrait réaliser sans appeler les api, et dans ce cas, je préfère utiliser fso.

Si nécessaire, un peu de lecture :
http://warin.developpez.com/access/fichiers/

cordialement,

Philippe