CopyFile ou FileCopy : lequel utiliser ?Résolu

Question

Voici une question pour les sp&#233;cialistes des API et du fonctionnnement des machines.

J'aimerais conna&#238;tre les avantage et inconv&#233;nient de ces deux fonctions sachant que :

- CopyFile est une fonction API
- File Copy est une commande DOS

Merci...

Programmix

cs_CanisLupus · Accepted Answer

filesystemobject n&#233;cessite scrrun.dll si tu te sers de la r&#233;f&#233;rence que j'ai indiqu&#233; plus haut. Sinon, tu peux t'en passer si tu d&#233;clares tout en Object. C'est ce qu'on fait en vbs, asp, ...

Pourquoi c'est &#224; &#233;viter ? J'aimerais bien aussi une r&#233;ponse pr&#233;cise quoique j'en connais quelques &#233;l&#233;ments. Mais si on va dans ce sens, il faut &#233;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&#233;nient en cas de chemin r&#233;seau.
Par ex, un dir("[file://\serveur\dossier \serveur\dossier]") plante si tu n'as pas de connexion r&#233;seau valide alors que dir("k:\dossier") te renvoie bien "" si k:\ ou k:\dossier n'existe pas.
Ces fonctions sont h&#233;rit&#233;es du DOS, faut pas leur en vouloir de ne pas savoir g&#233;rer correctement les chemins r&#233;seau.

Sinon, dans nombre de cas, j'utilise les api windows, je ne vais quand m&#234;me pas r&#233;inventer la roue &#224; chaque fois.

Loup Gris

valtrase · Answer

Salut,
Comme toutes Api le principal d&#233;faut c'est en cas de probl&#232;me. l'Api &#224; en effet de grandes chances de planter le pc. Donc &#224; utiliser avec parcimonie.

Cordialement, Jean-Paul  
______________________________________________________________________

Le Savoir n'a de valeur que s'il est partag&#233;

cs_PROGRAMMIX · Answer

OK pour le danger des API mais cela ne r&#233;pond pas &#224; ma question.
Dans le cas d'une "simple" copie de fichier, quelle est la meilleure des 2 pour travailler rapidement, s&#251;rement, facilement ?

Programmix

cs_CanisLupus · Answer

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 &#233;crases ou non le fichier destination (s'il existe d&#233;j&#224;) sans planter le prog alors qu'avec FileCopy, il faut que tu testes d'abord s'il existe d&#233;j&#224; avec un dir(...) et que tu utilises un Kill d'abord si tu veux l'&#233;craser ......

Tu as aussi les m&#233;thodes avec FileSystemObject (r&#233;f&#233;rence Microsoft Scripting runtime).

Fais ton choix

Loup Gris

cs_PROGRAMMIX · Answer

Voil&#224; qui est d&#233;j&#224; plus parlant.

Jusqu'&#224; maintenance, je n'ai jamais utilis&#233; les m&#233;thodes avec FileSystemObject.
Est-ce mieux ? 
Est-ce que cela ne n&#233;cessite pas des dll en plus en cas de d&#233;ploiement de l'application ?

Je programme en VB6 (et oui, toujours pas pass&#233; le cap).

Programmix

cs_Alain Proviste · Answer

filesystemobject est &#224; &#233;viter.

cs_PROGRAMMIX · Answer

Pourquoi ce "filesystemobject est &#224; &#233;viter" ?
Ne pourrais-tu d&#233;velopper un peu ta r&#233;ponse ?

Programmix

cs_PROGRAMMIX · Answer

Voil&#224;, maintenant c'est plus clair.

Programmix

ScSami · Answer

Moi aussi je voudrais bien savoir pourquoi le FSO est a &#233;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 &#224; autre chose car apr&#232;s tout le VB est quand m&#234;me fait pour d&#233;velopper rapidos sans se prendre le choux avec des consid&#233;rations inconsid&#233;r&#233;es je trouves. Sinon, ben faut passer au C.

cs_Alain Proviste · Answer

des consid&#233;rations inconsid&#233;r&#233;es ^^

ScSami · Answer

Ben vi, des consid&#233;rations inconsid&#233;r&#233;es !
Zolie expression n'est-il point ?

cs_CanisLupus · Answer

Alain, puisque tu es &#224; l'&#233;coute, que c'est toi qui a dis, sans autre explication, qu'il faut &#233;viter le filesystemobject et que tu es Admin CS, pourrais-tu nous &#233;clairer sur ce point plut&#244;t que sur la grammaire ?

Au passage, "consid&#233;rations inconsid&#233;r&#233;es" c'est du fran&#231;ais, m&#234;me si c'est maladroit, voir le dico. 
Par le jeu des synonymes, je pourrais m&#234;me dire en bon fran&#231;ais que je me demande pourquoi je consid&#232;re ta consid&#233;ration sur les "consid&#233;rations inconsid&#233;r&#233;es" alors que je consid&#232;re que cette consid&#233;ration, consid&#233;r&#233;e ou non, n'a pas lieu d'&#234;tre prise en consid&#233;ration dans le cas pr&#233;sent.

Loup Gris

ScSami · Answer

Heureusement pour moi la langue fran&#231;aise m'est pas aussi rigide que certains langages de programmation ou que certains esprits et le "dico" ne donne aucune contre-indication &#224; user de styles (vous savez, un peu comme les CSS ;-). Fallais bien entendu capter la l&#233;g&#232;re irone de l'apparent paradoxe de cette formule... vous l'avez remarqu&#233;, tant mieux.

Mais en effet, on aimerait tous ici avoir le point de vue, j'en suis intimement persuad&#233;, constructif, de Alain qui, je dois l'admettre m'intrigue (pas Alain, son point de vu bien s&#251;r!).

Surtout que personnellement, j'habuse passablement du FSO dans mes codes.

Alors, Alain, on t'&#233;coute :

cs_Alain Proviste · Answer

j'ai not&#233; que c'est amusant c'est tout je n'ai pas dit que c'&#233;tait incorrect :p
Pour FilesystemObject je le d&#233;conseille pour une raison simple, il est interm&#233;diaire entre l'api et vb : la m&#233;thode CopyFile d'un objet FSO est un appel &#224; l'api CopyFile, mais ce n'est pas toi g&#232;re l'appel l'api, ni vb, c'est le FSO. ( c'est pourquoi beaucoup d'utilisateurs l'aiment bien, c'est plus facile &#224; mettre en oeuvre que d&#233;claration + appel d'une api... ) 
Quand tu cr&#233;es un objet FSO, tu fais appel &#224; un certain nombres de constructeurs, ce qui ralenti l'&#233;x&#233;cution &#224; ce moment l&#224; mais peut etre interessant pour la suite, si on d&#233;teste manipuler les apis et si on a beaucoup d'op&#233;ration sur les fichiers/dossiers.
Mais m&#234;me dans ce cas, l'appel direct aux apis d&#233;clar&#233;es depuis vb est plus rapide que FSO car je le rep&#232;te, fso va se contenter d'appeller ces apis...
Il vaut mieux d&#233;clarer ses apis soit m&#234;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&#233;diaires pour faciliter la manipulation des objets...
Voil&#224; &#231;a n'est que ma propre opinion, en clair je pense qu'il vaut mieux utiliser sois les fonctions int&#233;gr&#233;es &#224; vb, sois les apis, car la cr&#233;ation de l'objet FSO en lui m&#234;me puis les constructeurs de FSO ralenti terriblement un code, alors que l'appel direct &#224; l'api depuis vb6 ralenti beaucoup moins.
Il me semble d'ailleur que y a une source ici sur vbfrance de moi-m&#234;me qui compare la vitesse par FSO et par api pour explorer un disque dur ( mais ca remonte &#224; tr&#232;s longtemps )

Faites vous votre propre opinion !

cs_Alain Proviste · Answer

hmm erreur de ma part :p
il ne s'agit pas d'une source pour explorer, juste pour recuperer les nom dos :)

cs_PROGRAMMIX · Answer

J'avais d&#233;pos&#233;e en son temps une source de ce genre permettant ainsi de comparer "3 M&#201;THODES DE RECHERCHE R&#201;CURSIVE DE FICHIERS" (
http://www.vbfrance.com/code.aspx?id=5089)

Mais  &#224; l'&#233;poque, je ne comprenais pas grand chose aux API.  Maintenant, j'en ai moins peur...

En voici la pr&#233;sentation :
Lorsque je me suis mis &#224; chercher des m&#233;thodes de recherche r&#233;cursive de fichiers, j'ai &#233;t&#233; confront&#233; &#224; des sources utilisant des m&#233;thodes diff&#233;rentes que j'ai cherch&#233; &#224; comprendre.
Puis voyant que ce th&#232;me &#233;tait souvent recherch&#233;, j'ai regroup&#233; 3 des m&#233;thodes rencontr&#233;es afin de montrer la mani&#232;re de travailler de chacune d'elles et surtout la vitesse &#224; laquelle elle tourne.

La premi&#232;re m&#233;thode est l'exemple livr&#233; par Microsoft avec Visual Basic : WINSEEK.VBP.
Celle-ci utilise les contr&#244;les DriveListBox, DirListBox et FileListBox pour effectuer ses recherches.

La deuxi&#232;me est celle de CML'S RECHERCHER (source n&#176;4404), que j'ai un peu modifi&#233; pour mes besoins.
Cette m&#233;thode utilise un contr&#244;le ListBox, des fonctions FileSystemObject et la fonction DIR

La troisi&#232;me m&#233;thode (et de loin la plus rapide) est celle provenant du fichier d'aide "apidocvb.chm" dont DARKSIDIOUS parle dans sa source n&#176;5690, "Aide sur les principales API".
Celle-ci utilise les API. Elle permet de r&#233;cup&#233;rer des noms de fichiers de type "~$ojet.doc" ce qui n'est pas le cas avec une FileBox.

Programmix

cs_CanisLupus · Answer

Voil&#224; une explication qu'elle est bonne ! 

Loup Gris

CopyFile ou FileCopy : lequel utiliser ?

17 réponses

Discussions similaires