Version imprimable
Est-il possible en c# d'utiliser la copie de fichier windows, c'est à dire avoir la même fenêtre que lors d'une copie avec l'explorateur.
J'utilise aussi Supercopier (clubic), cela permettrait de l'utiliser sans rien coder.
Qu'est-ce que vous en pensez ?
Merci d'avance !
sous .NET pour manipuler les fichiers il y a la classe File. Et notamment pour copier File.Copy() Inutile de se compliquer l'existence donc...
Mais pour faire ce que tu veux (utiliser la copie de Windows, avec l'ecran de copie), il faut passer par les API Windows ;)
Attention à cette démarche malgré tout, on réutilise tous les vieux trucs de l'API et à la fin on a une appli .NET qui fait sans cesse du p/invoke et qui n'a plus rien de .NET ;)Citation:
Envoyé par Morpheus
Il ne faut pas être extrémiste comme ça!! :lol:Citation:
Envoyé par Merlin
Si on a besoin de fonctionnalités qui ne sont pas dans .NET, on peut soit utiliser Win32, soit les coder en .NET.
Pour ma part j'utilise Win32 quand il n'y a pas d'équivalent .NET
File.Copy c'est bien mais il ne t'affiche pas les boites de dialogues comme le fait l'explorateur windows .... Et puis il bloque jusqu'à ce qu'il termine donc pour de gros fichiers tu dois le lancer dans un thread pour laisser la main à l'utilisateur
C'est un point de débat assez intéressant... C'est pas de l'extrémisme, juste du bon sens : Une appli .NET qui fait du p/invoke et qui contient du code unsafe posera des problèmes de droits d'exécution.Citation:
Envoyé par abelman
Tout appel à du code Win32, même un seul dans une appli de 1 million de ligne de code très pur, suffit à poser un problème de droit d'exécution.
Moralité c'est de mon point de vue à bannir. tout simplement.
On ne doit recourrir à du code win32 que s'il n'existe réelllement aucune autre solution (ce qui est très très rare donc). Et encore faudra-t-il isoler cet appel, dans un assemblage séparé par exemple (une classe de service dédiée) qui pourra facilement être localisé et changer pour du code .NET lorsqu'on aura trouvé le moyen de le faire en .NET.
Pour revenir à l'exemple, copie de fichier, la fonction .NET existe, on ne doit donc pas chercher midi à 14h.
La fonction .NET existe, on doit l'utiliser en priorité.
Il manque un dialogue ? ... création d'un contrôle utilisateur. C'est simple, ça reste .NET, c'est dans l'optique POO de réutilisation du code...
Il manque le multithreading, il suffit de l'ajouter au contrôle.
La programmation "patchwork" qui consiste à appeler un bout de Win32 parce qu'on trouve ça mieux, développer un truc en VB.NET parce que l'exemple de code qu'on a trouver sur le web est dans ce langage et qu'on ne veut pas le traduire, etc, etc, c'est malgré tout une méthode de travail qui n'est pas à conseiller. La cohérence est toujours payante dans le temps...
Effectivement ... Encore faut il en avoir du temps.Citation:
Envoyé par Merlin
Sur l'ensemble ton point de vue est bon, mais quand on est pressé on utilise l'existant :D
je sais qu'il faut être réaliste, mais d'expérience je sais aussi qu'on paye parfois très cher, mais plus tard, ce genre de "stratégie de l'urgence". La cohérence, elle, finit toujours par payer.Citation:
Envoyé par abelman
Si on écoute les utilisateurs ou les donneurs d'ordre, le soft est toujours à faire pour hier. Donc de toute façon c'est la logique de la pression maximale.
Une seule réponse à cela : ne pas tomber dans le panneau et prendre le temps de faire bien, c'est souvent beaucoup moins long qu'on le pense :-)