DECOUPEUR/FUSIONNEUR DE FICHIER RAPIDE

Commentaire de Exploreur le 14/02/2007 16:29:01

Salut,

Ben..Comme d'habitude Violent_Ken, tes sources sont toujours d'une utilitées....

A+
Exploreur

Commentaire de Exploreur le 14/02/2007 17:13:13

Salut Violent_Ken,

Je me suis mal exprimer dans mon premier post...Ce que j'ai voulu dire, c'est que tes sources sont utiles, mais je ne trouver pas de mot à la fin de cette phrase(tes sources sont toujours d'une utilitées....), pour l'expliquer..lol..
Tu penses bien qu'a mon niveau(et même si j'avais un niveau supérieur)je ne me permettrai pas de te critiquer ou te critiquer les autres(je ne suis pas comme cela)  

Excuse-moi pour ma mauvaise explication du premier post.

A+
Exploreur

Commentaire de Exploreur le 14/02/2007 17:51:29

Thanks

A+
Exploreur

Commentaire de violent_ken le 14/02/2007 20:44:50

Salut, merci pour ce commentaire constructif.

Alors :
- INVALID_HANDLE_VALUE=-1 bien sur, faute stupide

- les On error Resume Next proviennent d'un vaste copier/coller, mais effectivement avec uniquement des APIs c'est inutile

- "WriteBytesToFile(...) et peut-être ailleurs, TOUJOURS vérifier si hfile = -1 en retour de CreateFile." ==> oui

- Pour le mix API/fonctions VB, si tu veux parler de CreateEmptyFile, c'est une solution de rapidité. Généralement (dans tout mon code) l'argument curSize n'est jamais passé, donc sortie de fonction et donc uniquement API. Dans un seul endroit, il me faut une taille non nulle donc je remplit le fichier à l'arrache de zero bytes... c'est moche, je sais, j'ai codé vite.

- "FUITE MEMOIRE" ==> merci de m'avoir signalé ceci, je vais regarder

- EnumFolders, EnumFiles ==> ces fonctions ont été codées presque entièrement par ShareVB, donc je n'avais pas remarqué cette erreur (quoique pas dramatique). Je corrige.


Si tu as d'autres remarques, n'hésite surtout pas, çà permettra d'améliorer mon code.

Merci, @+

Commentaire de Renfield le 15/02/2007 07:44:25 administrateur CS

ca a l'air sympa

quelques remarques rapides

une barre de progression / un sablier ne seraient pas du luxe...
il FAUT bloquer la feuille quand il bosse : j'ai reclické sur lancé => Crash

je le trouve encore assez lent... évite de passer par une String comme tampon, et rassemble
GetBytesFromFile et WriteBytesToFile

évite d'ouvrir/fermer n fois tes fichiers

CreateFileEmpty inutile, le CreateFile dans WriteBytesToFile pourrait créer ton fichier.

y'a un soucis majeur dans ta gestion d'erreur :
If lFile = -1 Then Exit Function 'fichier indisponible

c'est bien beau, mais le découpage, derrière, continue ; pour lui tout s'est bien passé... et l'utilisateur n'en sais rien. Il ne pourra pourtant pas regrouper ses fichiers.

Commentaire de violent_ken le 15/02/2007 13:15:20

Salut, alors :

- les fichiers peuvent avoir une taille > 5Go, la taille est limitée par le currency (plusieurs To ==> pas de limite).
Par contre les fichiers résultants (les morceaux) ne peuvent, je pense, pas faire plus de 2Go (limité par le type Long).
Je dis çà sans avoir testé (je n'ai testé en pratique qu'un ghost de 4.5Go)

- barre de progression ==> oui, en plus j'ai déjà codé un OCX ProgressBar pour çà ;)

- bloquer la feuille ==> en effet, se serait judicieux

- CreateFileEmpty inutile ==> hum, de mémoire (pas VB sur ce PC et flemme de download ma source ^^) je passe un argument OPEN_EXISTING dans CreateFile, donc pas de création possible du fichier (je n'ai pas mis de CREATE_ALWAYS ni autre chose parce que cette fonction me sert dans un autre projet à écrire dans des fichiers déjà existants, et uniquement existants (pas de création si inexistant)).
Donc à priori, je vais garder CreateEmptyFile.

- évite d'ouvrir/fermer n fois tes fichiers ==> Tu veux dire avec CreateFile pour la récupération du handle ?? Si c'est çà, je peux récupérer le handle un seule fois et passer dans les fonctions ReadBytes et WriteBytes le handle, et pas le path.

- "y'a un soucis majeur dans ta gestion d'erreur..." ==> Hum. lFile = -1 n'est possible que dans le cas où le fichier est utilisé par un autre processus. Donc faudra rajouter un test de vérification avant de commencer la découpe pour voir si le handle récupéré est <> de INVALID_HANDLE_VALUE.

- "rassemble GetBytesFromFile et WriteBytesToFile" ==> oui, pourquoi pas, je vais voir çà.

- "je le trouve encore assez lent... évite de passer par une String comme tampon" ==> ;)
Effectivement c'est optimisable, mais disons qu'avec des strings c'est la solution de facilité. J'ai codé çà assez (très) rapidement... Mais je vais voir ce que je peux faire...
par contre, niveau vitesse, bah moi je fusionne/découpe à 14-5Mo/s... alors que en copie de fichiers simple, mes disques durs limitent la vitesse à 20Mo/s, donc le gain ne pourra pas être énorme de toutes façons.

Merci pour les commentaires, @+

Commentaire de BruNews le 15/02/2007 22:57:21 administrateur CS

Oh le vilain moqueur...
Sa V2 en C# fait les mêmes temps.

Commentaire de violent_ken le 15/02/2007 23:25:00

Ah en fait la v2 EST la source dont je parle. Bah disons que je m'était arrêté aux commentaires sur "les 10 minutes" sans voir qu'une mise à jour avait réglé tout çà.

Mais de toutes façons, le VB est bien plus lent quand même ...
@+

Commentaire de violent_ken le 15/02/2007 23:50:12

Certes, tu as sans doutes raison.

Mais bon, je vais terminer mon projet en cours, et je pense que quand il sera terminé complètement (bon ok, pas avant un moment), je me concentrerais par la suite davantage au C++.
Parce que tant qu'à faire, autant aller vers quelque chose de performant, non ?

@+

Commentaire de BruNews le 15/02/2007 23:55:37 administrateur CS

SUR !!!
Tu verras comme c'est agréable de pouvoir envisager nimporte quoi sans limitation.

Commentaire de Mikaels35 le 16/02/2007 07:58:38

Je signale un petit bug, si on ouvre la boite de sélection du fichier à découper et qu'on la ferme en cliquant sur la croix ou sur "annuler" sans avoir sélectionné de fichier on obtient un message d'erreur à la ligne:

  'récupère le FileName
    ShowOpen = Left$(OFName.lpstrFile, InStr(OFName.lpstrFile, vbNullChar) - 1)

Une petite gestion de l'erreur s'impose donc !

Sinon c'est pas mal du tout !

@+

Commentaire de BruNews le 16/02/2007 10:16:48 administrateur CS

Allons un peu de sérieux et surtout garder le sens critique par rapport à tout ce qui se dit et s'écrit.
Je ne suis plus tout jeune et des interprétés j'en ai vu arriver des tas, tous devaient remplacer le natif en raison de leur facilité, maintenabilité, etc... Résultat des courses, on n'a jamais fait le moindre soft correct autrement qu'en natif.
Le .NET n'est que le Nieme d'une longue liste et ne changera en rien la réalité, personne n'acceptera jamais d'aller faire ses courses en attendant le résultat d'un tri sur Excel.
Pourquoi donc Office, Sql Server et tous produits MS depuis 2002 ne sont pas en .net ? Ce qui est bon pour les autres ne le serait pas pour MS, trop drole. Simplement parce qu'un interprété est fait pour applets que les SSII fournissent aux clients qu'ils ont en contrat et absolument rien de plus, sera vendu un max et reviendra 2 francs 6 sous "codé" par des non informaticiens.
Combien vaut celui qui fait ce que tout un chacun peut faire en 15 jours de formation ?

Commentaire de Bidou le 16/02/2007 12:48:43 administrateur CS

Pas tout à fait d'accord, Brunews.

Il est évident que les langages managés on des limites, et il faut les connaître. Ce n'est pas pour autant qu'il faut les rabaisser à des langages "utilisés par des non-informaticiens et langages qui s'apprennent en 15 jours de formation".

De plus, même si le noyau d'un OS est écrit dans un langage natif, ça n'implique pas que ça soit le cas pour l'ensemble du système. Je prendrai comme seul exemple Windows Vista dont une partie du code a été écrit en .NET (notemment MMC et Media Center si je ne fais erreur).

Pour terminer, la source écrite en C# donc vous avez parlé (www.csharpfr.com/code.aspx?ID=28107) a certainement été écrite par débutant, car même si on ne peut pas atteindre la rapidité d'un code natif, on arrive bien entendu à beaucoup mieux qu'un 10min pour 700 Mo (si j'ai le temps, je vais d'ailleurs reprendre cette source pour la corriger).

Commentaire de hvb le 16/02/2007 14:23:01

je veux pas trop rentrer dans le débat, surtout "contre" brunews, mais le problème avec le c++ pour les jeunes et dans les petites boites comme la mienne, c'est qu'il (me) faudrait 3 jours pour ecrire la même chose qu'en .net en quelques heures... (pour certains cas bien sur, spécialement en info de gestion)
On a beau ne travailler qu'en c++ en cours, je n'arrive pas à accrocher pour mes projets persos/pro (pro est un grand mot dans mon cas)
Ma remarque n'apporte pas grand chose c'est vrai... et je n'ai rien à dire sur ta source violent_ken... je sors...

Commentaire de BruNews le 16/02/2007 15:32:16 administrateur CS

Office en .net, he he ne sont pas fous, c'est une des 2 principales sources de revenus de MS alors comme tout produit important il est en vrai code.
Manqué une grosse vague ??? L'échelle sociale, je ne la conçois que dans 1 seul sens, l'ascencion.

Commentaire de BruNews le 16/02/2007 16:37:50 administrateur CS

Ils avaient deja vocation à migrer depuis.... eh ben ils ont "oublié" de migrer.
.net vise le public anciennement sur VB et ceux qu'on ramène de Java, qlqs millions de par le monde, cad le gros des troupes.
Pour ce qui est du code et mode de fonctionnement, certain que c'est différent mais seulement dans le mode d'interprétation, VB était compilé "natif" en call vers sa VM, .net est en pseudo code interprété à chaque chargement dans une zone mémoire, ce qui d'ailleurs le rend encore plus lent à se lancer.
Je te rappelle que j'ai les sources Windows complètes depuis qlqs années (merci MS).

Commentaire de violent_ken le 16/02/2007 18:21:58

Voilà, c'est corrigé.

Je précise que la taille max des fichiers est supérieure à 9 To (type currency) mais que la seule limitation est que les fichiers résultants doivent faire moins de 2 Go chacun.

@+

Commentaire de violent_ken le 17/02/2007 09:36:20

Bon, sur la limite des 2Go par fichier, j'aurais très pu l'enlever mais en contrepartie j'aurais du utiliser un type Currency sur plusieurs variables (donc réduction de la vitesse dasn une certaine mesure).

Et d'ailleurs, on peut découper un gros backup (quelque soit sa taille) en un nombre sans limite de fichiers de 700Mo (700<2000).

Voilà....^^ @+

Commentaire de webernard le 09/12/2007 22:41:13

bonjour, je comprends pas grand chose à votre language, moi , je cherche juste un programme permettant par exemple de "fusionner 2 éxecutables en un seul, par exemple, je voudrait qu'un fichier setup.exe + un fichier patch.exe , se retrouvent tout deux dans un seul fichier.exe, qui, lorsqu'on le lance, lance en fait mes 2 fichiers originaux... je pensais que ce programme le faisait, est ce juste ?

si oui, question de super noob de la mort, comment fait on pour l'éxécuter ce fameux programme, car je l'ai téléchargé, et j'obtiens un zip, qui contient des fichiers bas, cls, etc... moi qui m'attendais à me retrouver avec un exe que je lance, et voilou... quelqu'un peut-il éclairer ma lanterne ?

Merci

Commentaire de webernard le 10/12/2007 04:45:10

Merci pour la réponse, je sens une légère ironie, justifiée, je n'en doute pas, mais tant qu'à faire, ce code source, il fait finalement ce que j'en attends, ou pas ? ( après pour ce qui est de le compiler, ça doit pouvoir se faire avec VB, je me donnerais la peine d'essayer de comprendre seul, mais je voudrais pas me casser la tête, alors que ce code ne fait pas le boulot que j'en attends...

(et oui, je cherchais plutôt un prog. servi sur un plateau sur un site à la téléchargez.com, car comme dit, la programmation ne m'as jamais attiré... )

malheureusement je n'ai pas trouvé ce que cherchais, je suis donc obligé d'élargir ma recherche ( je suis ouvert à toute suggestion... ^^ )