cs_MasterHack
Messages postés586Date d'inscriptionjeudi 18 septembre 2003StatutMembreDernière intervention13 février 20082 16 juil. 2005 à 13:57
salut, moi j'utilise fso en cas de programmation vbs car ça donne un grand avantage,mais au cas ou je programme sous vb je prefere passer par le billet des api ou des fonction predefinies.si non je ne suis pas contre fso.
cs_MasterHack
Messages postés586Date d'inscriptionjeudi 18 septembre 2003StatutMembreDernière intervention13 février 20082 16 juil. 2005 à 14:12
celui de pouvoire traiter les fichiers et repertoires sous vbs,si non tu devera creer t propres typelib en vb et les utliser en vbs a l'aide de createobject().le seul blem que j'ai avec fso c la presence des antivirus (script bloking), mais pour etre contre faut justifier ça aussi ,a vous :)
Neo.balastik
Messages postés796Date d'inscriptionjeudi 17 mai 2001StatutMembreDernière intervention 5 mai 20097 16 juil. 2005 à 16:49
Salut ;O)
FSO est fait pour le scripting. C'est là qu'on le retrouvera principalement. FSO étant un objet COM, il est bien évident qu'on peut l'utiliser à travers n'importe quel langage reconnaissant COM. FSO est très facile à utiliser et est présent sur Win2000 et XP et ultérieur. Pour un petit programme vite fait en VB ayant une diffusion limitée, pourquoi ne pas l'utiliser ?
Voici les arguments en sa défaveur :
- exécutable lié à différentes DLL (au moins 7 versions différentes ):
msvcrt.dll - Runtime Library
scrrnfr.dll - Ressources internationales de l'exécutable Script Microsoft
scrrun.dll - Microsoft Script Runtime
- il est possible de désactiver FSO pour une question de sécurité
Pour des développements à orientation professionnelle, il serait plus judicieux de s'en passer et de reproduire les fonctionnalités en pure VB avec l'utilisation d'API. Le code est sera beaucoup plus rapide car FSO est un gros lourdeau.
En ce qui me concerne, je n'utilise jamais FSO via VB6 mais je l'utilise en scripting.
cs_CanisLupus
Messages postés3757Date d'inscriptionmardi 23 septembre 2003StatutMembreDernière intervention13 mars 200620 16 juil. 2005 à 17:47
Salut,
Ok avec Neo.balastik, de toutes façons, le scripting est déjà lent (langage interprété). Une lourdeur de plus ou de moins ....
Pour nhervagault, kill et mkdir ne sont pas des API mais des instructions (ou fonctions) héritées des anciens vb qui les avaient héritées du DOS et conservées pour compatibilité.
Effectivement, kill et mkdir sont incapables de reconnaitre un chemin réseau (sans lettre logique).
Les API qui leur correspondent, et qui acceptent les chemins réseau, sont en vb6 :
DeleteFile et CreateDirectory
en vb.net :
System.IO.File.Delete et System.IO.Directory.CreateDirectory
En dehors du scripting, (quoique), il y a donc toujours une solution pour se passer du FSO qui, soit dit en passant n'est qu'un intermédiaire généraliste qui se sert lui-même des API.
Un de mes formateurs a dit : Utiliser FisSystemObject pour effectuer une simple action comme effacer un fichier c'est comme mobiliser une caserne de pompier entière pour écraser un moustique.
-------------------------------------------------
Dresseur de puces, .... normal pour un loup !?