CopyFile ou FileCopy : lequel utiliser ? [Résolu]

cs_PROGRAMMIX 1134 Messages postés mercredi 2 octobre 2002Date d'inscription 24 juillet 2011 Dernière intervention - 2 avril 2005 à 13:16 - Dernière réponse : cs_CanisLupus 3758 Messages postés mardi 23 septembre 2003Date d'inscription 13 mars 2006 Dernière intervention
- 10 avril 2005 à 20:13
Voici une question pour les spécialistes des API et du fonctionnnement des machines.

J'aimerais connaître les avantage et inconvénient de ces deux fonctions sachant que :

- CopyFile est une fonction API
- File Copy est une commande DOS

Merci...

Programmix
Afficher la suite 

17 réponses

cs_CanisLupus 3758 Messages postés mardi 23 septembre 2003Date d'inscription 13 mars 2006 Dernière intervention - 2 avril 2005 à 16:40
+3
Utile
filesystemobject nécessite scrrun.dll si tu te sers de la référence que j'ai indiqué plus haut. Sinon, tu peux t'en passer si tu déclares tout en Object. C'est ce qu'on fait en vbs, asp, ...

Pourquoi c'est à éviter ? J'aimerais bien aussi une réponse précise quoique j'en connais quelques éléments. Mais si on va dans ce sens, il faut éviter tellement de choses en vb qu'il vaut mieux abandonner tout de suite.

Personnellement, j'utilise le plus souvent FileCopy, Dir et Kill sachant qu'il y a un inconvénient en cas de chemin réseau.
Par ex, un dir("[file://\\serveur\dossier \\serveur\dossier]") plante si tu n'as pas de connexion réseau valide alors que dir("k:\dossier") te renvoie bien "" si k:\ ou k:\dossier n'existe pas.
Ces fonctions sont héritées du DOS, faut pas leur en vouloir de ne pas savoir gérer correctement les chemins réseau.

Sinon, dans nombre de cas, j'utilise les api windows, je ne vais quand même pas réinventer la roue à chaque fois.

Loup Gris
Cette réponse vous a-t-elle aidé ?  
cs_PROGRAMMIX 1134 Messages postés mercredi 2 octobre 2002Date d'inscription 24 juillet 2011 Dernière intervention - 2 avril 2005 à 19:39
+3
Utile
Voilà, maintenant c'est plus clair.

Programmix
Cette réponse vous a-t-elle aidé ?  
valtrase 936 Messages postés lundi 19 janvier 2004Date d'inscription 17 mars 2017 Dernière intervention - 2 avril 2005 à 13:23
0
Utile
Salut,
Comme toutes Api le principal défaut c'est en cas de problème. l'Api à en effet de grandes chances de planter le pc. Donc à utiliser avec parcimonie.

Cordialement, Jean-Paul
______________________________________________________________________

Le Savoir n'a de valeur que s'il est partagé
cs_PROGRAMMIX 1134 Messages postés mercredi 2 octobre 2002Date d'inscription 24 juillet 2011 Dernière intervention - 2 avril 2005 à 13:43
0
Utile
OK pour le danger des API mais cela ne répond pas à ma question.
Dans le cas d'une "simple" copie de fichier, quelle est la meilleure des 2 pour travailler rapidement, sûrement, facilement ?

Programmix
cs_CanisLupus 3758 Messages postés mardi 23 septembre 2003Date d'inscription 13 mars 2006 Dernière intervention - 2 avril 2005 à 13:48
0
Utile
Salut,

Si tu prog en vb.net, tu as aussi :
System.IO.File.Copy(CheminFichierDepart, CheminFichierArrivee)

Sinon, avec l'api CopyFile, en une seule ligne de commande, tu peux dire si tu écrases ou non le fichier destination (s'il existe déjà) sans planter le prog alors qu'avec FileCopy, il faut que tu testes d'abord s'il existe déjà avec un dir(...) et que tu utilises un Kill d'abord si tu veux l'écraser ......

Tu as aussi les méthodes avec FileSystemObject (référence Microsoft Scripting runtime).

Fais ton choix

Loup Gris
cs_PROGRAMMIX 1134 Messages postés mercredi 2 octobre 2002Date d'inscription 24 juillet 2011 Dernière intervention - 2 avril 2005 à 13:56
0
Utile
Voilà qui est déjà plus parlant.

Jusqu'à maintenance, je n'ai jamais utilisé les méthodes avec FileSystemObject.
Est-ce mieux ?
Est-ce que cela ne nécessite pas des dll en plus en cas de déploiement de l'application ?

Je programme en VB6 (et oui, toujours pas passé le cap).

Programmix
cs_Alain Proviste 910 Messages postés jeudi 26 juillet 2001Date d'inscription 1 février 2015 Dernière intervention - 2 avril 2005 à 14:08
0
Utile
filesystemobject est à éviter.
cs_PROGRAMMIX 1134 Messages postés mercredi 2 octobre 2002Date d'inscription 24 juillet 2011 Dernière intervention - 2 avril 2005 à 14:35
0
Utile
Pourquoi ce "filesystemobject est à éviter" ?
Ne pourrais-tu développer un peu ta réponse ?

Programmix
ScSami 1490 Messages postés mercredi 5 février 2003Date d'inscription 3 décembre 2007 Dernière intervention - 10 avril 2005 à 07:10
0
Utile
Moi aussi je voudrais bien savoir pourquoi le FSO est a éviter!!!
Il est tellement pratique que le bon vieux DOS et autres APIs que franchement, s'en passer serait, pardonnez-moi, une connerie puisqu'il existe et fonctionne parfaitement!

Et comme dit le loup, si faut s'en passer, autant passer à autre chose car après tout le VB est quand même fait pour développer rapidos sans se prendre le choux avec des considérations inconsidérées je trouves. Sinon, ben faut passer au C.
cs_Alain Proviste 910 Messages postés jeudi 26 juillet 2001Date d'inscription 1 février 2015 Dernière intervention - 10 avril 2005 à 17:08
0
Utile
des considérations inconsidérées ^^
ScSami 1490 Messages postés mercredi 5 février 2003Date d'inscription 3 décembre 2007 Dernière intervention - 10 avril 2005 à 17:25
0
Utile
Ben vi, des considérations inconsidérées !
Zolie expression n'est-il point ?
cs_CanisLupus 3758 Messages postés mardi 23 septembre 2003Date d'inscription 13 mars 2006 Dernière intervention - 10 avril 2005 à 18:31
0
Utile
Alain, puisque tu es à l'écoute, que c'est toi qui a dis, sans autre explication, qu'il faut éviter le filesystemobject et que tu es Admin CS, pourrais-tu nous éclairer sur ce point plutôt que sur la grammaire ?

Au passage, "considérations inconsidérées" c'est du français, même si c'est maladroit, voir le dico.
Par le jeu des synonymes, je pourrais même dire en bon français que je me demande pourquoi je considère ta considération sur les "considérations inconsidérées" alors que je considère que cette considération, considérée ou non, n'a pas lieu d'être prise en considération dans le cas présent.

Loup Gris
ScSami 1490 Messages postés mercredi 5 février 2003Date d'inscription 3 décembre 2007 Dernière intervention - 10 avril 2005 à 18:54
0
Utile
Heureusement pour moi la langue française m'est pas aussi rigide que certains langages de programmation ou que certains esprits et le "dico" ne donne aucune contre-indication à user de styles (vous savez, un peu comme les CSS ;-). Fallais bien entendu capter la légère irone de l'apparent paradoxe de cette formule... vous l'avez remarqué, tant mieux.

Mais en effet, on aimerait tous ici avoir le point de vue, j'en suis intimement persuadé, constructif, de Alain qui, je dois l'admettre m'intrigue (pas Alain, son point de vu bien sûr!).

Surtout que personnellement, j'habuse passablement du FSO dans mes codes.

Alors, Alain, on t'écoute :
cs_Alain Proviste 910 Messages postés jeudi 26 juillet 2001Date d'inscription 1 février 2015 Dernière intervention - 10 avril 2005 à 19:40
0
Utile
j'ai noté que c'est amusant c'est tout je n'ai pas dit que c'était incorrect :p
Pour FilesystemObject je le déconseille pour une raison simple, il est intermédiaire entre l'api et vb : la méthode CopyFile d'un objet FSO est un appel à l'api CopyFile, mais ce n'est pas toi gère l'appel l'api, ni vb, c'est le FSO. ( c'est pourquoi beaucoup d'utilisateurs l'aiment bien, c'est plus facile à mettre en oeuvre que déclaration + appel d'une api... )
Quand tu crées un objet FSO, tu fais appel à un certain nombres de constructeurs, ce qui ralenti l'éxécution à ce moment là mais peut etre interessant pour la suite, si on déteste manipuler les apis et si on a beaucoup d'opération sur les fichiers/dossiers.
Mais même dans ce cas, l'appel direct aux apis déclarées depuis vb est plus rapide que FSO car je le repète, fso va se contenter d'appeller ces apis...
Il vaut mieux déclarer ses apis soit même pour savoir ce qui existe et comment ca se manipule, dans l'optique de manipuler de mieux en mieux les apis, car il n'y a pas toujours des scripts intermédiaires pour faciliter la manipulation des objets...
Voilà ça n'est que ma propre opinion, en clair je pense qu'il vaut mieux utiliser sois les fonctions intégrées à vb, sois les apis, car la création de l'objet FSO en lui même puis les constructeurs de FSO ralenti terriblement un code, alors que l'appel direct à l'api depuis vb6 ralenti beaucoup moins.
Il me semble d'ailleur que y a une source ici sur vbfrance de moi-même qui compare la vitesse par FSO et par api pour explorer un disque dur ( mais ca remonte à très longtemps )

Faites vous votre propre opinion !
cs_Alain Proviste 910 Messages postés jeudi 26 juillet 2001Date d'inscription 1 février 2015 Dernière intervention - 10 avril 2005 à 19:43
0
Utile
hmm erreur de ma part :p
il ne s'agit pas d'une source pour explorer, juste pour recuperer les nom dos :)
cs_PROGRAMMIX 1134 Messages postés mercredi 2 octobre 2002Date d'inscription 24 juillet 2011 Dernière intervention - 10 avril 2005 à 20:11
0
Utile
J'avais déposée en son temps une source de ce genre permettant ainsi de comparer "3 MÉTHODES DE RECHERCHE RÉCURSIVE DE FICHIERS" (
http://www.vbfrance.com/code.aspx?id=5089)

Mais à l'époque, je ne comprenais pas grand chose aux API. Maintenant, j'en ai moins peur...

En voici la présentation :
Lorsque je me suis mis à chercher des méthodes de recherche récursive de fichiers, j'ai été confronté à des sources utilisant des méthodes différentes que j'ai cherché à comprendre.
Puis voyant que ce thème était souvent recherché, j'ai regroupé 3 des méthodes rencontrées afin de montrer la manière de travailler de chacune d'elles et surtout la vitesse à laquelle elle tourne.

La première méthode est l'exemple livré par Microsoft avec Visual Basic : WINSEEK.VBP.
Celle-ci utilise les contrôles DriveListBox, DirListBox et FileListBox pour effectuer ses recherches.

La deuxième est celle de CML'S RECHERCHER (source n°4404), que j'ai un peu modifié pour mes besoins.
Cette méthode utilise un contrôle ListBox, des fonctions FileSystemObject et la fonction DIR

La troisième méthode (et de loin la plus rapide) est celle provenant du fichier d'aide "apidocvb.chm" dont DARKSIDIOUS parle dans sa source n°5690, "Aide sur les principales API".
Celle-ci utilise les API. Elle permet de récupérer des noms de fichiers de type "~$ojet.doc" ce qui n'est pas le cas avec une FileBox.

Programmix
cs_CanisLupus 3758 Messages postés mardi 23 septembre 2003Date d'inscription 13 mars 2006 Dernière intervention - 10 avril 2005 à 20:13
0
Utile
Voilà une explication qu'elle est bonne !

Loup Gris

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.