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

Messages postés
1134
Date d'inscription
mercredi 2 octobre 2002
Dernière intervention
24 juillet 2011
- 2 avril 2005 à 13:16 - Dernière réponse :
Messages postés
3758
Date d'inscription
mardi 23 septembre 2003
Dernière intervention
13 mars 2006
- 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

Meilleure réponse
Messages postés
3758
Date d'inscription
mardi 23 septembre 2003
Dernière intervention
13 mars 2006
2 avril 2005 à 16:40
3
Merci
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

Merci cs_CanisLupus 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 93 internautes ce mois-ci

Meilleure réponse
Messages postés
1134
Date d'inscription
mercredi 2 octobre 2002
Dernière intervention
24 juillet 2011
2 avril 2005 à 19:39
3
Merci
Voilà, maintenant c'est plus clair.

Programmix

Merci cs_PROGRAMMIX 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 93 internautes ce mois-ci

Messages postés
936
Date d'inscription
lundi 19 janvier 2004
Dernière intervention
17 mars 2017
2 avril 2005 à 13:23
0
Merci
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é
Messages postés
1134
Date d'inscription
mercredi 2 octobre 2002
Dernière intervention
24 juillet 2011
2 avril 2005 à 13:43
0
Merci
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
Messages postés
3758
Date d'inscription
mardi 23 septembre 2003
Dernière intervention
13 mars 2006
2 avril 2005 à 13:48
0
Merci
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
Messages postés
1134
Date d'inscription
mercredi 2 octobre 2002
Dernière intervention
24 juillet 2011
2 avril 2005 à 13:56
0
Merci
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
Messages postés
910
Date d'inscription
jeudi 26 juillet 2001
Dernière intervention
1 février 2015
2 avril 2005 à 14:08
0
Merci
filesystemobject est à éviter.
Messages postés
1134
Date d'inscription
mercredi 2 octobre 2002
Dernière intervention
24 juillet 2011
2 avril 2005 à 14:35
0
Merci
Pourquoi ce "filesystemobject est à éviter" ?
Ne pourrais-tu développer un peu ta réponse ?

Programmix
Messages postés
1490
Date d'inscription
mercredi 5 février 2003
Dernière intervention
3 décembre 2007
10 avril 2005 à 07:10
0
Merci
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.
Messages postés
910
Date d'inscription
jeudi 26 juillet 2001
Dernière intervention
1 février 2015
10 avril 2005 à 17:08
0
Merci
des considérations inconsidérées ^^
Messages postés
1490
Date d'inscription
mercredi 5 février 2003
Dernière intervention
3 décembre 2007
10 avril 2005 à 17:25
0
Merci
Ben vi, des considérations inconsidérées !
Zolie expression n'est-il point ?
Messages postés
3758
Date d'inscription
mardi 23 septembre 2003
Dernière intervention
13 mars 2006
10 avril 2005 à 18:31
0
Merci
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
Messages postés
1490
Date d'inscription
mercredi 5 février 2003
Dernière intervention
3 décembre 2007
10 avril 2005 à 18:54
0
Merci
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 :
Messages postés
910
Date d'inscription
jeudi 26 juillet 2001
Dernière intervention
1 février 2015
10 avril 2005 à 19:40
0
Merci
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 !
Messages postés
910
Date d'inscription
jeudi 26 juillet 2001
Dernière intervention
1 février 2015
10 avril 2005 à 19:43
0
Merci
hmm erreur de ma part :p
il ne s'agit pas d'une source pour explorer, juste pour recuperer les nom dos :)
Messages postés
1134
Date d'inscription
mercredi 2 octobre 2002
Dernière intervention
24 juillet 2011
10 avril 2005 à 20:11
0
Merci
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
Messages postés
3758
Date d'inscription
mardi 23 septembre 2003
Dernière intervention
13 mars 2006
10 avril 2005 à 20:13
0
Merci
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.