FILESYSTEMLIBRARY, TOUT (+ QUE FSO) SUR LES FICHIERS/DOSSIERS/DISQUES
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 2010
-
22 avril 2007 à 15:12
hex_man
Messages postés28Date d'inscriptionmercredi 21 novembre 2001StatutMembreDernière intervention12 décembre 2007
-
12 déc. 2007 à 20:45
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
hex_man
Messages postés28Date d'inscriptionmercredi 21 novembre 2001StatutMembreDernière intervention12 décembre 2007 12 déc. 2007 à 20:45
Salut,
Je voulais te dire que ton truc c hyper violent et super complet, que demande le peuple;)
Chapeau!!!
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 19 mai 2007 à 10:01
Salut, oui, tu as parfaitement raison, c'est très lourd de récupérer une info par le GetFolder.
Donc en l'occurence, si tu veux récupérer le DateCreated de n folders beaucoup plus rapidement, tu feras :
1) s()=clsFile.EnumFoldersStr (ce qui ne récupère qu'un tableau de strings, pas d'objets)
2)
For x=1 to ubound(s())
....= GetFolderDates(s(x)).datecreated
Ainsi, on évite les étapes 2,3 et 4 que tu cites ;) On ne récupères QUE les dates, on n'a qu'à instancier une seule fois en début de prog Set clsFile = New FileSystem.
On n'utilisera GetFolder que pour récupérer toutes les infos sur un dossier, sinon on préferera la méthode que je viens de citer.
@+
lokovbf
Messages postés11Date d'inscriptionjeudi 1 septembre 2005StatutMembreDernière intervention 1 avril 2011 18 mai 2007 à 12:58
d'abord bravo pr ta classe:
ca va me servir ds mon job parfois le fso de m$ laisse à désirer
voici qq suggestions à 1ere vue pr optimiser :
désolé car facile de critiquer, pas eu trop le tps d'examiner ta dll ou de bien rédiger, et me trompe peut-etre ds mon analyse
=> A toi de voir...
- En general pr optimiser:
attention, ton syst est assez lourd (normal, vu l'ampleur de ton boulot.)
mai vb étant ultra-lent: limite un max les encapsulages/intermerdiaires avant l'operation finale (ta dll serait nickel en c/c++...)
Quitte à etre moins 'propre', à perdre qq fonctionnalités plus 2aires (car ta dll est suffisament riche)
=> un ex du pb: on veut lire la prop de n répertoires
for each ... in ....
Set cFol = FS.GetFolder(Path,true)
... = cFol.DateCreated <-- c'est ca qui interesse
next
0) set FS= new FileSystem ' ok
1) FileSystem.GetFolder(Path) :
Set GetFolder = New Folder
GetFolder.SetPath(Path, True) ' 1er intermedaire : ok
2) Folder.Class_Initialize
Set clsFile = New FileSystem ' RE-filesystem: AIE!
3) Folder.SetPath(Path,true)
MyFolder.Path = Path
If RefreshInformations (<=true) Then Call RefreshInfos
4) RefreshInfos()
clsFile.GetFolderDates_HANDLE .GetShortPath .GetParentFolderName etc... etc...
' AIE AIE: => N accès au disque. tu extrait TOUTES les props dont je n'avais pas besoin et la, ca peut faire ramer
c'est pire avec la classe File ou on y rajoute des GetAssociatedProgram CompressedFileSize GetFileExtension etc...
je te file qq solutions ds les autres post
si tu fais evoluer ton code, ca m'interesse bcp.
bon courage et bravo
MadM@tt
Messages postés2167Date d'inscriptionmardi 11 novembre 2003StatutMembreDernière intervention16 juillet 20091 1 mai 2007 à 14:19
cs_JLN
Messages postés371Date d'inscriptionsamedi 1 juin 2002StatutMembreDernière intervention17 juin 2013 30 avril 2007 à 11:58
Merci pour ta réponse, et en y repensant c'est vrai qu'il vaux mieux avoir qu'une seule librairie à utiliser dans une appli plutot que 2. Et je le redis c'est du bon boulot !
Bonne prog à tous...
@+ JLN
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 30 avril 2007 à 11:12
Salut, merci pour l'info ^^
Par contre j'ai regardé le code : un Timer (interval 100) et un DriveListBox, c'est pas ce qu'il y a de plus rapide ;)
Sinon pour W98, il va y avoir du boulot (erf), plusieurs APIs (déjà toutes celles finissant en -Ex) n'existent pas sur cet OS.
@+
cs_drissou
Messages postés160Date d'inscriptiondimanche 7 décembre 2003StatutMembreDernière intervention14 janvier 2009 30 avril 2007 à 11:01
VIOLENT_KEN
Super tes classes.
je sui toujours bloqué car je n'ai pas eu le temps de modifer pour que cela focntionne sur Win 98, mais là n'est pas le problème..
je ne sais pas si cela t'intéresse, mais sur PSC il y a un prog pour détecter l'ajout ou la suppression de lecteurs
http://www.planet-source-code.com/vb/scripts/ShowCode.asp?lngWId=1&txtCodeId=68456 peut être à ajouter pour avoir ce suivi
personnelement je n'ai pas testé non plus mais dans ce vaste projet que tu construis..
Drissou
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 30 avril 2007 à 09:41
Bah de toutes façons, tout existe déjà un peu !
Nous avions besoin de méthodes et de fonctions sur les fichiers/dossiers/disques pour la VbSystemLibrary... donc j'ai repris du code que j'avais déjà codé, je l'ai réorganisé amélioré et l'ai complété pour arriver à çà.
Cela existe déjà, certes, mais si tu veux parler de FSO, ce code est plus complet et plus rapide que la dll Scripting de microsoft.
"Mais n'aurait-il pas mieux value ne s'occuper que de l'inexistant ?" ==> bah non, je pense qu'il fallait mieux tout reprendre, même les trucs de bases (FileExists, DeleteFile...). Imagine une library qui soit dépendante d'une autre library ! Il était donc bien nécessaire de tout refaire.
Et c'est tellement bien de tout recoder soi-même ^^.... même si certains diront que c'est contraire au principe de base de VB qui consiste à réutiliser en masse ce qui est déjà existant (OCX, Dll activeX...)
@+
cs_JLN
Messages postés371Date d'inscriptionsamedi 1 juin 2002StatutMembreDernière intervention17 juin 2013 30 avril 2007 à 09:23
Super tu as réinventé la roue... Bon je plaisante, très bon code, mais quelle était l'idée de départ pour vouloir réencoder tout ca ? Je sais tout n'existe pas... Mais n'aurait-il pas mieux value ne s'occuper que de l'inexistant ? Sinon c'est du bon et on peut dire même du très bon code.
Bonne prog à tous...
@+ JLN
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 29 avril 2007 à 19:55
Nouvelle MAJ : correction d'un bug critique qui empechait de récupérer les bonnes infos sur les drives.
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 28 avril 2007 à 16:21
Cà y est c'est bon...
Au programme de cette MAJ :
- ajout des fonctions GetFolderDateAsCurrency et GetFileDateAsCurrency
- ajout de la recherche de fichiers/dossiers multicritères.
Les critères possibles sont : taille, nom, dates (les 3).
Il faut remplir un type perso pour personnaliser sa recherche.
J'ai implémenté une interface pour la recherche ==> il existe deux "events", ItemFound et SearchIsFinished.
Pour en bénéficier, il faut mettre "Implements ISearchEvent" dans le code de la form...
Voilà un exemple de définition des critère de recherche (avec lancement de la recherche en récupérant un objet, avec l'utilisation de l'interface) :
La méthode de recherche est :
1) récupération de tous les fichiers (ou dossiers) avec un enum
2) test de chaque fichier (ou dossier) avec les critères ==> valide ou pas le fichier (ou dossier)
Galain ==> les attributs sont déjà définis en une classe. 32 est affiché dans la textbox, mais dans l'IDE, l'autocomplétion de propose de manière textuelle les différents attributs.
Pour l'interface, c'est peut être pas ce qu'il y a de plus propre, à vous de me le dire ^^
@+ (j'arrête pour aujourd'hui sauf si bugs...)
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 28 avril 2007 à 14:21
Seb ==> je viens de me rendre compte que j'avais mal lu ta remarque quand j'ai répondu pour le Loop la première fois (pas vu le Exit Do).
Tu avais évidemment raison.
@+
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 28 avril 2007 à 14:20
Salut,
Seb ==> Exit Do, yep, bonne idée. Pour les tlb, je regarderai ! Si on gagne beaucoup de temps lors des appels aux APIs, çà peut valloir le coup de changer.
Galain ==>
-Attributs, pour GetFileAtributes ? Ok, je passerais cette variable de type FileAttributes (un enum plus explicite)
-FileCompressedSize ==> En fait, je pense que le mieux serait de décomposer GetFileSizes en GetFileSize et GetCompressedFileSize ==> évite tous les problèmes
-FirstSector ==> ok ;) C'est un exemple de lecture du premier secteur du disque. Mais comme il y a généralement des &h0 dans le début du disque (qui "coupent" la string), la textbox n'affiche que 2/3 caractères...
salut Violent_Ken
Bravo pour cette classe mais 3 petites remarques
1° Attributs = 32 n'est pas très parlant : il faudrait trouver une astuce pour détailler ces attributs de façon pour clair
2° FileCompressedSize : oui mais ne devrait apparaître que seulement si le fichier est compressé et le positionner dans la liste après FileSize
3) FirstSector : je ne comprends pas la signification de ce paramètre disque
Mais va-s'y doucement : les touches de ton clavier doivent sûrement commencer à chauffer
A+
draluorg
Messages postés625Date d'inscriptionvendredi 23 avril 2004StatutMembreDernière intervention25 novembre 2010 28 avril 2007 à 14:08
Oup's sorry autant pour moi j'avais pas vu que tu instanciais tes classes dans le Class_initialize!
Sinon pour le Do While oui en effet de cette facons tu es obligé de reverifier a chaque boucle! donc c'est pour ca que je dis autant ne pas mettre de while et sortir de la boucle des qu'on a un INVALID_HANDLE_VALUE...
Pour la tlb c'est un peu comme les #include en C/C++ mais bon je vais pas m'etendre sur ce sujet que je connais aussi tres peu!
En gros les avantages sont:
Jusqu'a 15 de gains sur l'APPEL a une fonction
Tes déclares ne sont pas dans ton projets mais dans un fichier de reference (fichier qui sera compiler avec le projet donc pas besoin de le distribuer avec ton exe)
Eb et RenField ont chacun déposé une source qui permet de les generer et pourront mieux t'expliquer que moi
++
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 28 avril 2007 à 13:19
Salut, merci pour ce commentaire :
- "Do While hDrive <> INVALID_HANDLE_VALUE" ==> En fait, je viens de tester, il s'avère que l'on sort de la boucle lors du Loop, si la condition n'est plus vérifiée.
Donc si jamais hDrive=-1, il y aura une appel à EnumPhysicalDisks avant de sortir de la boucle...enfin il me semble
-"Si oui tu peux peut etre instancier une ClsFile dans le Class_Initialize et la supprimer dans le Class_Terminate et utiliser toujours celle la dans ta clsFolder... (perso c'est ce que je fais mais je sais pas si ca change grand choses)" ==> C'est très précisémment ce que j'ai fait dans toutes les classes objet ,je n'instancie que lors du Initialize() et libère lors du Terminate().
Pour la Tlb, j'avoue que je ne comprend pas suffisement le concept pour effectuer cette modification, du moins pour l'instant ^^ Si cela gagne beaucoup en perf, je vais m'y intéresser sérieusement... ;)
@+
draluorg
Messages postés625Date d'inscriptionvendredi 23 avril 2004StatutMembreDernière intervention25 novembre 2010 28 avril 2007 à 13:10
Salut a tous,
J'ai enfin trouvé le temps de jetter un oeil a ta big class ^^
Bravo pour le fameux boulot!
Sinon cote optimisation j'ai vu des ptites choses du genre:
Do While hDrive <> INVALID_HANDLE_VALUE
hDrive = CreateFile....
If hDrive <> INVALID_HANDLE_VALUE Then
Call EnumPhysicalDisks....
End If
Loop
Pourquoi ne pas faire directement
Do
hDrive = CreateFile....
If hDrive = INVALID_HANDLE_VALUE Then exit do
Call EnumPhysicalDisks....
loop
Bon je chipote je te l'accorde!
Autre point mais je ne suis pas sur a ce niveau la..
Quand dans une classe genre ClsFolder tu appel clsFile.kelkeschoses ca instance a chaque fois une nouvelle classe non ?
Si oui tu peux peut etre instancier une ClsFile dans le Class_Initialize et la supprimer dans le Class_Terminate et utiliser toujours celle la dans ta clsFolder... (perso c'est ce que je fais mais je sais pas si ca change grand choses)
Sinon je dirais aussi de faire une Tlb au moins pour les api les plus appelés.
En tout cas ta classe est vraiment sympa encore bravo!
++
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 28 avril 2007 à 13:02
J'attaque l'interface - grâce au tuto de Renfield - pour la recherche, en ce moment.
J'ai juste une question : suis-je obligé de passer en paramètre de ma fonction de recherche la form qui implémente l'interface ?
(je suis pas encore trop à l'aise avec les interfaces)
Merci, @+
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 28 avril 2007 à 11:58
Ahhhh bah ça commence à être interressant cette histoire :p
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 28 avril 2007 à 09:10
Ok pour l'anglais ^^
Sinon, j'ai remis un *.zip avec l'exemple.
@+
Renfield
Messages postés17287Date d'inscriptionmercredi 2 janvier 2002StatutModérateurDernière intervention27 septembre 202174 28 avril 2007 à 06:46
idem, en british sera plus aisément distribuable
MadM@tt
Messages postés2167Date d'inscriptionmardi 11 novembre 2003StatutMembreDernière intervention16 juillet 20091 28 avril 2007 à 02:40
Ah je viens de télécharger le zip et il n'y a pas le projet d'exemple
Pour la description de chaque fonction, je pense que si tu peux le faire, l'anglais est la meilleure solution, mais ça n'engage que moi ^^
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 27 avril 2007 à 21:47
Oui j'oubliais : j'ai ajouté aussi les propriétés FolderName (dans File) et DriveName (dans File et Folder).
Autre chose, j'ai oublié de remercier EB pour sa classe avec le code ASM dedans ^^
Encore une chose, j'ai laissé les déclarations des fonctions Search... dans FileSystem, elles ne sont pas faites, mais c'est prévu.
Dernière chose ==> je compte mettre plus tard (quand j'aurais le courage :p) la description de chaque fonction dans les attributs de procédure.
La question étant : en anglais ou en français ??
Enjoy, @+
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 27 avril 2007 à 21:43
Salut, en voilà une MAJ qu'elle est grosse...
Au menu :
1) suppression d'un tout petit bug qui empechait de récupérer
les infos de la classe PhysicalDisk
2) Changé la langue (c'est de l'anglais dans l'exemple, paske j'ai posté également cette source sur un site anglais)
3) Ajout de nombreuses fonctions, à savoir :
Dans FileSystem :
-FusionFiles (fusion de fichier découpés)
-CutFile (découpage de fichier)
-SetFileDates (pour changer les dates d'un fichier)
-SetFolderDates
-SetVolumeLabel (changer le label d'un disque)
-SanitizeFile
-SanitizeDrive
-SanitizePhysicalDisk
-CompareFiles (compare 2 fichiers)
-CreateIsoFromDrive (créé un fichier ISO depuis un disque)
Dans File :
-SetDates
-DriveName
-FolderName
-Sanitize
-CutFile
Dans Drive :
-Sanitize
-SetVolumeLabel
-CreateIso
Dans PhysicalDrive :
-Sanitize
Je n'ai pu tester SanitizeDrive et SanitizePhysicalDisk (la dernière est d'ailleurs nouvelle) car pas de disque sous la main, si quelqu'un pouvait confirmer le bon fonctionnement...
Merci, @+
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 26 avril 2007 à 22:50
Ok j'ajouterais tout...
Demain çà va coder sec ^^ (je vois déjà les 5000 lignes dans FileSystem.cls)
@+
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 26 avril 2007 à 22:42
tout ce qui tourne autour du filesysteme doit etre ajouté apres une fois que t'aura un gros gros gros paquet de code bien compact... t'optimises. Une fois optimisé... tu ajoutes et ainsi de suite :p
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 26 avril 2007 à 22:22
Erf ! Faudrait pas que ce soit le jour et la nuit quand même... paske si on appelle la procédure à chaque fichier trouvé, ou bien tout les 500 fichier scannés, çà va faire beaucoup de temps perdu !
Et au fait, devrais-je de ton avis ajouter les autres fonctions citées précédemment ?
@+
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 26 avril 2007 à 22:19
Pas probablement... surement !
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 26 avril 2007 à 22:08
Papa Renfield, c'est vrai ^^
Sinon t'as raison, une interface sera beaucoup plus "sure" pour l'user. Bien que probablement plus lente ?
@+
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 26 avril 2007 à 22:03
Un callback sur pointeur c'est tres rapide, mais c'est une methode typiquement "C" qui peut planter l'application et l'ide. Hors le principe du vb c'est justement d'eviter ça et d'offrir au programmeur une couche de controle d'acces a la memoire. Donc partant du principe qu'une lib n'est pas destiné a celui qui la crée mais a tout ceux qui vont l'utiliser autant penser comme un "vébiste" de base c'est a dire "A bah moi je veux que ce soit simple et que j'ai pas besoin de 15 tonne de code pour faire la petite application que mon boss ma demandé"
Bref, j'arrete la sinon je vais m'auto-stresser.
Papa Renfield s'il vous plait :p
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 26 avril 2007 à 21:57
Ma dernière question et puis j'arrête de flooder :p
Devrais-je ajouter des fonctions du genre :
-découpage/fusion de fichier
-création d'un fichier ISO depuis un lecteur CD/DVD
-comparaison de fichiers
-...etc
?
@+
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 26 avril 2007 à 21:49
moi pas programmer directx !
Mais quel est le problème avec le pointeur de fonction ? Ok c'est limité au VB6 (pas antérieur) avec AddressOf, mais çà tourne bien (comme CopyFileEx par exemple).
Cela étant, j'avoue que l'interface me semble carrément mieux ! Je vais en plus pouvoir mettre en application ce que m'a appris Renfield !
@+
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 26 avril 2007 à 21:42
un pointeur de fonction ???? en vb ???? mais naaaan une interface et puis c'est bon ! regarde directx il a compris lui :p
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 26 avril 2007 à 21:38
EB ==> ok pour le private.
lol pour "mavar = TextBox1" ;) Bien sur je l'ai déjà fait ^^ Mais c'est tellement laid que j'ai arrêté :p
Bon donc dans mon élan de folie, je rajoute la recherche multi-critères ??
(si oui, je suppose qu'il faut prévoir en param l'adresse d'une fonction de callback pour la progression ?)
Et je proposerai même les properties de date en écriture... puisqu'il faut être complet...
@+ (et merci Galain !!)
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 26 avril 2007 à 21:35
J'ai mis un 10/10 pour Violent_Ken et je te mettrais un 11/10 si il rajoute "Sanitize" !!!!!!!!!!!
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 26 avril 2007 à 21:33
classe->propriete->instancing->private
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 26 avril 2007 à 21:31
Ok c'est bon j'y vais ^^
Mais faudra pas se plaindre si quelqu'un fait
Call FS.GetDrive("C").Sanitize :p
Au passage : sais tu comment cacher ta classe pour éviter que l'utilisateur la voit dans la liste de l'autocomplétion ?
Et pendant que j'y suis (^_^), quel est l'intérêt profond de définir une "Procédure par défaut" (mis à part pour le flemmard qui veut pas tapper ".Path") ??
@+ (donc pas de MAJ ce soir, mais demain !)
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 26 avril 2007 à 21:26
C'est simple un bibliotheque de fonction sa sert a quoi ? Ca sert a etre simple et surtout exaustif ! Sinon autant ce taper des lignes de code et virer la lib ! Maintenant c'est dangereu alors je le met pas... dans ce cas la autant enlever toute les fonctions de vb car suffit d'utiliser "shell","kill" voir simplement New pour flinguer windows. Ce n'est donc pas la fonction qui est dangereuse mais la personne qui l'utilise. Enfin bref si c'est la "taille" ou la "complexite" d'un code qui te fait peur tu ne metras jamais rien de bien dans ta lib, ce qui fait la difference avec les autres lib pourri que personne ne telecharge telement il y en a des floppé c'est justement le fait qu'elle offre des fonction et des possibilites que les autres n'ont pas alors va y petit !!
hahah faut que j'arrete la coke :p
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 26 avril 2007 à 21:21
Galain ==> oui, oui, j'ai lu trop vite mon code ^^ Tout à fait vrai.
Mais personne ne trouve dangereux de mettre la méthode "Sanitize" dans un objet Drive, PhysicalDisk ou File ????
Pour Violent_Ken la valeur 1 en Currency est représentée sur 64 bits par la valeur 10000 équivalente en binaire : donc il faut diviser par 10000 pour retrouver la valeur binaire correcte 1 sur 64 bits et ensuite on multiplie cette valeur par Bytespersector pour avoir le pointeur sur le premier octet à lire ou écrire
Pour Eb : d'accord avec toi je l'ajouterai; cela ne mange pas de pain
A+ les gars
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 26 avril 2007 à 21:09
Ou alors va falloir alléger tout çà pour la VbSystemLibrary.
@+ (désolé pour le double post, vade retro tabulation)
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 26 avril 2007 à 21:08
lol ;) C'est pas la taille le problème^^
C'est entre autres le fait qu'il faille rajouter une classe (que d'ailleurs je ne sais pas masquer pour l'utilisateur !) et quelques centaines de lignes pour la sanitization, les fonctions Friend prenant un param un pointeur...etc.
Puis "la" grosse question est : est-ce raisonnable de mettre ce bout de code somme toutes dangereux et d'une utilisation relativement rare dans une library qui a pour objectif de remplacer FSO "au quotidien" (enfin perso :p) ??
Peut être que oui en fait...je sais pas trop...
En disant "moi je l'ajouterais...." tu vas finir par me le faire mettre dedans ! lol
@+
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 26 avril 2007 à 21:00
Comment ça trop lourd lol, ma classe fait tout juste 120 lignes !!
J'en connais ils font des convertisseurs euro/franc avec 10x plus de code :p
Surtout pour un "FileSystem", moi je l'ajouterais...
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 26 avril 2007 à 20:58
Erf, je suis trop bête...
Dsl pour ce triple post...
@+
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 26 avril 2007 à 20:56
Mais j'y pense... pas besoin de diviser par 10000 dans le code ?
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 26 avril 2007 à 20:53
Ah oui, je vois l'optimisation, c'est sur que l'on y gagne (car plus d'appel à une Function et donc pas d'attribution des valeurs aux param en byref).
"En faisant (P/10000) * B au de (P*B)/10000 on multiplie..." ==> exact... j'essaie de le prendre en compte dans mes codes pour éviter l'overflow, c'est une erreur de ne pas l'avoir mis !
Merci pour ce commentaire constructif.
Je vais faire une MAJ ce soir je pense (correction de bugs, optimisations et ajout de nouvelles fonctions).
us_30 ==> Finalement je ne mettrais pas la sanitization, car trop lourd à mon gout (ASM de EB...etc).
Tu as écrit : "J'ai aussi changé la fonction GetLargeInteger et l'est remplacée par une version avec CopyMemory que m'a fournie Galain ==> elle est trois fois plus rapide qu'avant."
Ca c'est une bonne nouvelle
Mais on peut aller plus vite
Dans un module on déclare
Public Part32(0 to 1 ) as long ' 2 Long 32 bits
ensuite inspire toi de ma Sub d'accès direct disque
Public Sub DirectReadWrite(ByVal iStartSec As Currency, ByVal nbytes As Long, accesrw As Byte)
' Attention le nombre d'octets lus ou écrits ainsi que l'offset du premier octet lu ou écrit
' doivent impérativement être un multiple de la taille d'un secteur de disque
' Istartsec et nbytes doivent être des multiples de 512 ( taille standard des secteurs des disques)
Dim Bytesread As Long
Dim Byteswrite As Long
Dim ret As Long
On Error GoTo dskerror
dskerr = False
If hDevice& <> 0 Then CloseHandle hDevice&
'ouvre le drive
hDevice& = CreateFile(ldrive$, GENERIC_READ Or GENERIC_WRITE, FILE_SHARE_READ Or FILE_SHARE_WRITE, 0&, OPEN_EXISTING, 0&, 0&)
'quitte si le handle n'est pas valide
If hDevice& INVALID_HANDLE_VALUE Then dskerr True: Exit Sub
' on vide les buffers internes et on dévérouille la zone
Call FlushFileBuffers(hDevice&)
Call UnlockFile(hDevice&, Part32(0), Part32(1), nbytes&, 0)
End Select
'ferme le handle
CloseHandle hDevice
Exit Sub
dskerror:
dskerr = True
CloseHandle hDevice
End Sub
Ainsi on évite 2 Copymemory et j'espère que le temps gagné n'est pas gaché par l'accès à 2 variables tableau
Autre chose : Garder la syntaxe de la ligne car ainsi on multiplie l'étendue des secteurs accessibles
Soit P Pointeur et B Bytespersector
En faisant (P/10000) * B au de (P*B)/10000 on multiplie l'étendue des secteurs accessibles par B : on divise d'abord et on multiplie ensuite
Mais les limites du type Currency sont encore loin d'être atteinte : il nous faudrait des disques durs énormes pour les dépasser (922 337 203 685 477 octets pour être précis : valeur entière max d'un Currency positif)
A + et bravo pour tes codes
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 25 avril 2007 à 13:06
EB ==> lol !!
Sinon, effectivement, la recherche de fichiers/dossiers n'est pas inclue, il n'y a qu'un listing des fichiers/dossiers qui est possible.
Pour l'utilitaire d'effacement des fichiers, j'avais pensé à l'inclure, mais je me suis dit que çà allourdirait quelque peu la classe pour une utilisation au finale assez rare.
Je vais y réfléchir, voir si c'est pas trop lourd à inclure, mais déjà merci pour ces propositions ! (et merci également pour avoir signalé le bug que je corrigerai ce soir).
@+
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 25 avril 2007 à 00:28
us_30> va dire ça a ma femme ! hahahah
us_30
Messages postés2065Date d'inscriptionlundi 11 avril 2005StatutMembreDernière intervention14 mars 201610 24 avril 2007 à 23:29
Re-salut à tous,
J'ai pas trop résisté, j'ai jetté un petit coup d'oeil, tout de même... Pour l'instant j'ai vu qu'une simple coquille dans info lecteur, pour le calcul en pourcentage de libre. Cela renvoi le pourcentage occupé à la place... ah ! -);
Sinon, en présentation tu demandes aussi des idées de fonction... Il me semble (sauf erreur) que tu n'as pas de fonction de recherche de fichier, de dossier, avec le critère nom ou avec le contenu, comme dans l'exploreur... voir avec n'importe quel critère (ou presque) par exemple, la date de création, d'accès, etc... enfin, bon on peut aller loin comme ça... voir en combinaison de critères (multi-critères). Exemple, avec la date de création et contenant tel info... Long programme...
Il y a pas longtemps, il me semble également que tu avais codé un "Broyeur de fichier", je ne crois pas l'avoir vu dedans. A rajouter si c'est bien le cas, enfin c'est une idée.
A noter, que j'avais fait également une fonction similaire (peut-être encore plus élaborée, mais qu'en VB donc beaucoup moins rapide) pour effacer toute trace d'un fichier, certes, mais il me sert après un cryptage de fichier. En effet, il est un peu bête de crypter un fichier, si sa forme non cryptée est seulement effacé par un simple DELETE... De plus, pour des fichiers déjà éffacés (delete), il est intéressant de pouvoir aussi "broyer" leurs traces. Donc, j'avais aussi codé un remplissage jusqu'à saturation du disque, (avant effacement). Après essai par plusieurs programmes de type FileRecovery, on peut constater qu'ils ne peuvent plus rien retrouver... donc, voici une idée... mais bon, c'est très spécifique, j'en conviens... De plus dans le volume où windows garde son fichier d'échange, on ne peut pas tout faire... voir si on peut faire mieux...
Voilà, déjà...
Amicalement,
Us.
PS : EBArtSoft : On peut aussi avoir petit et rapide...
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 24 avril 2007 à 22:50
us_30 ==> Merci ;)
EB ==> Bah, l'important c'est que çà tourne vite ^^ D'ailleurs avec le CreateFile unique, c'est plutôt pas trop mal (en tout cas comparé à avant...)
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 24 avril 2007 à 16:03
Voilà c'est bon, plus de référence douteuse à Scripting et en même temps j'ai viré un bug sur strDriveType/DriveType de la classe Drive.
@+
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 24 avril 2007 à 15:54
Mince ! J'ai laissé la référence à scripting pour mes benchs...
Je change çà de suite !
@+
Renfield
Messages postés17287Date d'inscriptionmercredi 2 janvier 2002StatutModérateurDernière intervention27 septembre 202174 24 avril 2007 à 15:51
Pas simple a compiler l'exe, la scripting runtime est repassée au dessus de ta lib, dans les priorités... (merci vb^^)
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 24 avril 2007 à 15:17
(version *non _HANDLE)
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 24 avril 2007 à 15:14
MAJ 2 :
- suppression de certains enum en double
- suppression de la classe clsDef qui était VRAIMENT inutile
- suppression des déclarations de constantes et de variables inutiles
- suppression d'un bug énorme dans GetDriveVolumeInformation_HANDLE ==> retour à la version son _HANDLE ==> "seulement" un gain de 65% de temps par rapport à la version 1
@+
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 24 avril 2007 à 14:56
Voilà la MAJ 1 qui règle les problèmes d'optimisations de manière assez bonne :
Par rapport à la précédente version :
- gain sur la fonction GetFile : 10% de temps en moins
- gain sur la fonction GetPhysicalDisk : 30 % de temps en moins
- gain sur la fonction GetFolder : 40 % de temps en moins
- gain sur la fonction GetDrive : 80% de temps en moins (oui je sais... !!)
Par contre j'ai du rajouter 600 lignes de code...
J'ai aussi changé la fonction GetLargeInteger et l'est remplacée par une version avec CopyMemory que m'a fournie Galain ==> elle est trois fois plus rapide qu'avant.
J'ai aussi rajouté un CloseHandle qui manquait dans GetPhysicalDiskName.
Voilà, çà commence a être vraiment rapide !
@+ (je regarde les typelibs)
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 23 avril 2007 à 20:45
Ok, je me renseigne sur les typelibs ;)
Merci, @+
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 23 avril 2007 à 19:58
ya que ça dedans ?
bah crée une typlib ! ou ajoute les enum dans une autre classe...
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 23 avril 2007 à 19:55
En fait, cette classe contient les types et les enums publics... donc pas moyen de la mettre en private !
@+
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 23 avril 2007 à 19:41
Le mieu c'est de la placer en mode instancing "private" puis tu l'utilises normallement dans les procedure interne a ta dll puis en type "object" lorsque que exporte une procedure (c'est totalement invisible mais accessible via idispatch).
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 23 avril 2007 à 19:10
Ah ok, effectivement !
Alors le meilleur compromis serait-il de faire :
- CreateFile une fois lors du RefreshInfos de la classe Drive
- récupérer les infos par des fonctions Friend de FileSystem avec le handle en param
- CloseHandle à la fin de la sub RefreshInfo
?
Autre chose pendant que je t'ai sous la main ^^ ==> sais tu comment cacher la classe clsDef pour le projet utilisant la dll ?
Merci, @+
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 23 avril 2007 à 19:06
haha laisse tomber je suis hors limite, Cerveau overflow !
Non je voulais dire que si tu temporise toute les variables pour accelerer l'acces aux proprietes tu va te retrouver avec des disque qui n'existe plus. Je prends comme exemple une clef usb que l'on retire
:p
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 23 avril 2007 à 19:02
"attention a ne pas trop stocker ! car si on insert un disque amovible la classe ne le detecte plus..." ==> J'avoue que j'ai pas trop saisi ??
@+
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 23 avril 2007 à 18:55
attention a ne pas trop stocker ! car si on insert un disque amovible la classe ne le detecte plus...
:p
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 23 avril 2007 à 18:33
Ah oups, j'avais pas vu ton msg entre les miens ^^
Effectivement, c'est plus logique que les properties ne récupèrent pas elles-même les infos (enfin je crois) ! Laissons çà aux functions ^^
Par contre, gros problème encore avec les Drives/Disks. J'espère que c'est l'appel à CreateFile() pour récupérer le handle du drive qui est très lent, parce que sinon je vois pas trop comment optimiser...
A ton avis, est ce grave d'avoir un handle du disque "ouvert" durant toute la vie d'une variable de type Drive ou PhysicalDisk ??
Parce si c'est pas grave, je récupère une seule fois le handle dans le Class_Initialize du Drive/PhysicalDisk, je le stocke en private (et éventuellement je le propose en Property Get) et ensuite j'appelle des fonctions déclarées en Friend dans FileSystem avec comme paramètre le handle du disque ==> gain de 5 ou 6 appel à l'API CreateFile par GetDrive.
A ton avis, c'est une bonne idée ou pas ??
@+
MadM@tt
Messages postés2167Date d'inscriptionmardi 11 novembre 2003StatutMembreDernière intervention16 juillet 20091 23 avril 2007 à 18:24
Si si c'est très clair, et c'est super d'avoir laissé la possibilité de récupérer qu'une seule info, ce qui fait bien sur gagner du temps.
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 23 avril 2007 à 18:20
Cette source récupère des infos 50% plus vite que FSO sur les dossiers !
Par contre elle est beaucoup, beaucoup plus lente sur les accès aux infos sur les disques... Je vais essayer de réparer un peu çà en ne récupérant qu'une seule fois le handle avec CreateFile.
Mais je crains que l'écart de temps sur les disques demeure vraiment élevé...
@+
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 23 avril 2007 à 18:06
En conclusion :
- cette source est bien plus rapide que FSO
- si on veut récupérer qu'une info (exemple les attributs), on fera "maclasse.GetFileAttributes(file)" et non "maclasse.GetFile(file).Attributes" (qui récupère toutes les infos)
- si on veut récupérer toutes les infos sur un fichier, on fera "set cFile=maclasse.GetFile(file) puis info=cFile.PROPERTY"...etc
Je vérifie que c'est pareil avec les classes Folder et Drive...
@+
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 23 avril 2007 à 17:58
Ah bah bravo FSO....
Je viens faire le test de récupération des infos sur un fichier avec FSO vs cette source...
Pour la récupération de 500*22 infos, ma source est plus rapide de 50%... Et en plus, quand on fait .GetFile avec cette source, on récupère BEAUCOUP PLUS d'infos qu'avec le GetFile de FSO....
Autrement dit cette source est vraiment plus rapide, même si effectivement un bête ".GetFile().Size" sera plus rapide avec FSO (car ne récupère que la Size avec FSO, et récupère tout avec ma source).
Pas sur d'être très clair...
Je fait les tests avec les classes Drive et Folder...
@+
MadM@tt
Messages postés2167Date d'inscriptionmardi 11 novembre 2003StatutMembreDernière intervention16 juillet 20091 23 avril 2007 à 17:53
lol ah oui ok
Mais c'est mieux comme ça, car si tu accède 2 fois de suite à la propriété il la met à jour 2 fois c'est bete, et en plus c'est une propriété, pas une fonction, donc une propriété dans la logique, c'est qqch de fixe que l'ont récupère, alors que la fonction sous-entend un traitement pour la trouver (enfin c'est comme ça que je voit les choses du haut de ma chaise), mais y'a surement d'autres points de vue ^^
Sinon effectivement 200 ms c'est mieux que 1,5s
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 23 avril 2007 à 17:48
thx EB ;) (si tu as des idées pour optimiser la vitesse...^^)
J'ai refait quelques tests : GetDrive ne met aujourd'hui plus que 200ms... je vois pas du tout pourquoi hier c'était 1500 ??
Et de plus, quand on fait un GetFile, un GetDrive ou un GetFolder avec FSO, AUCUNE info n'est récupérée...c'est quand on fait GetFile().PROPERTY que l'info est récupérée !
Donc normal que ce soit beaucoup plus rapide...puisque çà ne récupère pas d'infos !!
Je vais faire des benchs comparatifs réels d'obtention d'infos entre FSO et cette source.
@+
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 22 avril 2007 à 21:17
sympa :)
MadM@tt
Messages postés2167Date d'inscriptionmardi 11 novembre 2003StatutMembreDernière intervention16 juillet 20091 22 avril 2007 à 17:17
Nooonn à ce point la ! Effectivement c'est bien mieux avec for each
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 22 avril 2007 à 16:04
D'ailleurs au passage : tu as vu sur le screenshot le temps mis par For Each In ?
Carrément plus rapide comme méthode...
@+
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 22 avril 2007 à 16:01
C'est vrai que c'était assez long... ;)
Enfin le problème c'est que ce n'est pas assez rapide.
L'appel à GetDrive() pour mon HDD contenant Windows met... 1.5 secondes !!
Bon ok, toutes les infos sont récupérées mais quand même, ce temps est énorme !
De même pour les fichiers, 500 fois GetFile() met quand même 800 ms... beaucoup plus que FSO.
Y a moyen d'optimiser en ne récupérant qu'une seule fois le handle des objets, mais par contre faudrait mettre plusieurs fonctions/APIs/ENUM dans les objets...
@+
MadM@tt
Messages postés2167Date d'inscriptionmardi 11 novembre 2003StatutMembreDernière intervention16 juillet 20091 22 avril 2007 à 15:50
Vraiment excellent comme code, c'est un truc de bourrin de recoder tout ça lol.
Sinon il faut pas se fier à l'aperçu du contenu du zip, chez moi il affiche que la dll mais en téléchargant on tombe bien sur le zip complet
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 22 avril 2007 à 15:12
Je sais que c'est pas vraiment optimisé...
Donc si vous avez LA MOINDRE IDEE POUR OPTIMISER CE CODE, merci d'en m'en faire part !
12 déc. 2007 à 20:45
Je voulais te dire que ton truc c hyper violent et super complet, que demande le peuple;)
Chapeau!!!
19 mai 2007 à 10:01
Donc en l'occurence, si tu veux récupérer le DateCreated de n folders beaucoup plus rapidement, tu feras :
1) s()=clsFile.EnumFoldersStr (ce qui ne récupère qu'un tableau de strings, pas d'objets)
2)
For x=1 to ubound(s())
....= GetFolderDates(s(x)).datecreated
Ainsi, on évite les étapes 2,3 et 4 que tu cites ;) On ne récupères QUE les dates, on n'a qu'à instancier une seule fois en début de prog Set clsFile = New FileSystem.
On n'utilisera GetFolder que pour récupérer toutes les infos sur un dossier, sinon on préferera la méthode que je viens de citer.
@+
18 mai 2007 à 12:58
ca va me servir ds mon job parfois le fso de m$ laisse à désirer
voici qq suggestions à 1ere vue pr optimiser :
désolé car facile de critiquer, pas eu trop le tps d'examiner ta dll ou de bien rédiger, et me trompe peut-etre ds mon analyse
=> A toi de voir...
- En general pr optimiser:
attention, ton syst est assez lourd (normal, vu l'ampleur de ton boulot.)
mai vb étant ultra-lent: limite un max les encapsulages/intermerdiaires avant l'operation finale (ta dll serait nickel en c/c++...)
Quitte à etre moins 'propre', à perdre qq fonctionnalités plus 2aires (car ta dll est suffisament riche)
=> un ex du pb: on veut lire la prop de n répertoires
for each ... in ....
Set cFol = FS.GetFolder(Path,true)
... = cFol.DateCreated <-- c'est ca qui interesse
next
0) set FS= new FileSystem ' ok
1) FileSystem.GetFolder(Path) :
Set GetFolder = New Folder
GetFolder.SetPath(Path, True) ' 1er intermedaire : ok
2) Folder.Class_Initialize
Set clsFile = New FileSystem ' RE-filesystem: AIE!
3) Folder.SetPath(Path,true)
MyFolder.Path = Path
If RefreshInformations (<=true) Then Call RefreshInfos
4) RefreshInfos()
clsFile.GetFolderDates_HANDLE .GetShortPath .GetParentFolderName etc... etc...
' AIE AIE: => N accès au disque. tu extrait TOUTES les props dont je n'avais pas besoin et la, ca peut faire ramer
c'est pire avec la classe File ou on y rajoute des GetAssociatedProgram CompressedFileSize GetFileExtension etc...
je te file qq solutions ds les autres post
si tu fais evoluer ton code, ca m'interesse bcp.
bon courage et bravo
1 mai 2007 à 14:19
http://vbsystemlibrary.free.fr/
Bonne journée à tous !
30 avril 2007 à 11:58
Bonne prog à tous...
@+ JLN
30 avril 2007 à 11:12
Par contre j'ai regardé le code : un Timer (interval 100) et un DriveListBox, c'est pas ce qu'il y a de plus rapide ;)
Sinon pour W98, il va y avoir du boulot (erf), plusieurs APIs (déjà toutes celles finissant en -Ex) n'existent pas sur cet OS.
@+
30 avril 2007 à 11:01
Super tes classes.
je sui toujours bloqué car je n'ai pas eu le temps de modifer pour que cela focntionne sur Win 98, mais là n'est pas le problème..
je ne sais pas si cela t'intéresse, mais sur PSC il y a un prog pour détecter l'ajout ou la suppression de lecteurs
http://www.planet-source-code.com/vb/scripts/ShowCode.asp?lngWId=1&txtCodeId=68456
peut être à ajouter pour avoir ce suivi
personnelement je n'ai pas testé non plus mais dans ce vaste projet que tu construis..
Drissou
30 avril 2007 à 09:41
Nous avions besoin de méthodes et de fonctions sur les fichiers/dossiers/disques pour la VbSystemLibrary... donc j'ai repris du code que j'avais déjà codé, je l'ai réorganisé amélioré et l'ai complété pour arriver à çà.
Cela existe déjà, certes, mais si tu veux parler de FSO, ce code est plus complet et plus rapide que la dll Scripting de microsoft.
"Mais n'aurait-il pas mieux value ne s'occuper que de l'inexistant ?" ==> bah non, je pense qu'il fallait mieux tout reprendre, même les trucs de bases (FileExists, DeleteFile...). Imagine une library qui soit dépendante d'une autre library ! Il était donc bien nécessaire de tout refaire.
Et c'est tellement bien de tout recoder soi-même ^^.... même si certains diront que c'est contraire au principe de base de VB qui consiste à réutiliser en masse ce qui est déjà existant (OCX, Dll activeX...)
@+
30 avril 2007 à 09:23
Bonne prog à tous...
@+ JLN
29 avril 2007 à 19:55
28 avril 2007 à 16:21
Au programme de cette MAJ :
- ajout des fonctions GetFolderDateAsCurrency et GetFileDateAsCurrency
- ajout de la recherche de fichiers/dossiers multicritères.
Les critères possibles sont : taille, nom, dates (les 3).
Il faut remplir un type perso pour personnaliser sa recherche.
J'ai implémenté une interface pour la recherche ==> il existe deux "events", ItemFound et SearchIsFinished.
Pour en bénéficier, il faut mettre "Implements ISearchEvent" dans le code de la form...
Voilà un exemple de définition des critère de recherche (avec lancement de la recherche en récupérant un objet, avec l'utilisation de l'interface) :
With MySearch
.Criteria = SearchName + SearchSize + SearchDateLastAccessed
.DateLastAccessedOperator = [ <= ]
.DateLastAccessedValue = "24/04/2007 17:45:12"
.SearchName = ".exe"
.SizeOperator = [ > ]
.SizeValue = 50000
.RespectCase = True
.SubFolder = True
.FolderName = "C:\Program Files"
End With
Call FS.SearchForFiles(MySearch, True, Me)
La méthode de recherche est :
1) récupération de tous les fichiers (ou dossiers) avec un enum
2) test de chaque fichier (ou dossier) avec les critères ==> valide ou pas le fichier (ou dossier)
Galain ==> les attributs sont déjà définis en une classe. 32 est affiché dans la textbox, mais dans l'IDE, l'autocomplétion de propose de manière textuelle les différents attributs.
Pour l'interface, c'est peut être pas ce qu'il y a de plus propre, à vous de me le dire ^^
@+ (j'arrête pour aujourd'hui sauf si bugs...)
28 avril 2007 à 14:21
Tu avais évidemment raison.
@+
28 avril 2007 à 14:20
Seb ==> Exit Do, yep, bonne idée. Pour les tlb, je regarderai ! Si on gagne beaucoup de temps lors des appels aux APIs, çà peut valloir le coup de changer.
Galain ==>
-Attributs, pour GetFileAtributes ? Ok, je passerais cette variable de type FileAttributes (un enum plus explicite)
-FileCompressedSize ==> En fait, je pense que le mieux serait de décomposer GetFileSizes en GetFileSize et GetCompressedFileSize ==> évite tous les problèmes
-FirstSector ==> ok ;) C'est un exemple de lecture du premier secteur du disque. Mais comme il y a généralement des &h0 dans le début du disque (qui "coupent" la string), la textbox n'affiche que 2/3 caractères...
@+
28 avril 2007 à 14:09
Bravo pour cette classe mais 3 petites remarques
1° Attributs = 32 n'est pas très parlant : il faudrait trouver une astuce pour détailler ces attributs de façon pour clair
2° FileCompressedSize : oui mais ne devrait apparaître que seulement si le fichier est compressé et le positionner dans la liste après FileSize
3) FirstSector : je ne comprends pas la signification de ce paramètre disque
Mais va-s'y doucement : les touches de ton clavier doivent sûrement commencer à chauffer
A+
28 avril 2007 à 14:08
Sinon pour le Do While oui en effet de cette facons tu es obligé de reverifier a chaque boucle! donc c'est pour ca que je dis autant ne pas mettre de while et sortir de la boucle des qu'on a un INVALID_HANDLE_VALUE...
Pour la tlb c'est un peu comme les #include en C/C++ mais bon je vais pas m'etendre sur ce sujet que je connais aussi tres peu!
En gros les avantages sont:
Jusqu'a 15 de gains sur l'APPEL a une fonction
Tes déclares ne sont pas dans ton projets mais dans un fichier de reference (fichier qui sera compiler avec le projet donc pas besoin de le distribuer avec ton exe)
Eb et RenField ont chacun déposé une source qui permet de les generer et pourront mieux t'expliquer que moi
++
28 avril 2007 à 13:19
- "Do While hDrive <> INVALID_HANDLE_VALUE" ==> En fait, je viens de tester, il s'avère que l'on sort de la boucle lors du Loop, si la condition n'est plus vérifiée.
Donc si jamais hDrive=-1, il y aura une appel à EnumPhysicalDisks avant de sortir de la boucle...enfin il me semble
-"Si oui tu peux peut etre instancier une ClsFile dans le Class_Initialize et la supprimer dans le Class_Terminate et utiliser toujours celle la dans ta clsFolder... (perso c'est ce que je fais mais je sais pas si ca change grand choses)" ==> C'est très précisémment ce que j'ai fait dans toutes les classes objet ,je n'instancie que lors du Initialize() et libère lors du Terminate().
Pour la Tlb, j'avoue que je ne comprend pas suffisement le concept pour effectuer cette modification, du moins pour l'instant ^^ Si cela gagne beaucoup en perf, je vais m'y intéresser sérieusement... ;)
@+
28 avril 2007 à 13:10
J'ai enfin trouvé le temps de jetter un oeil a ta big class ^^
Bravo pour le fameux boulot!
Sinon cote optimisation j'ai vu des ptites choses du genre:
Do While hDrive <> INVALID_HANDLE_VALUE
hDrive = CreateFile....
If hDrive <> INVALID_HANDLE_VALUE Then
Call EnumPhysicalDisks....
End If
Loop
Pourquoi ne pas faire directement
Do
hDrive = CreateFile....
If hDrive = INVALID_HANDLE_VALUE Then exit do
Call EnumPhysicalDisks....
loop
Bon je chipote je te l'accorde!
Autre point mais je ne suis pas sur a ce niveau la..
Quand dans une classe genre ClsFolder tu appel clsFile.kelkeschoses ca instance a chaque fois une nouvelle classe non ?
Si oui tu peux peut etre instancier une ClsFile dans le Class_Initialize et la supprimer dans le Class_Terminate et utiliser toujours celle la dans ta clsFolder... (perso c'est ce que je fais mais je sais pas si ca change grand choses)
Sinon je dirais aussi de faire une Tlb au moins pour les api les plus appelés.
En tout cas ta classe est vraiment sympa encore bravo!
++
28 avril 2007 à 13:02
J'ai juste une question : suis-je obligé de passer en paramètre de ma fonction de recherche la form qui implémente l'interface ?
(je suis pas encore trop à l'aise avec les interfaces)
Merci, @+
28 avril 2007 à 11:58
28 avril 2007 à 09:10
Sinon, j'ai remis un *.zip avec l'exemple.
@+
28 avril 2007 à 06:46
28 avril 2007 à 02:40
Pour la description de chaque fonction, je pense que si tu peux le faire, l'anglais est la meilleure solution, mais ça n'engage que moi ^^
27 avril 2007 à 21:47
Autre chose, j'ai oublié de remercier EB pour sa classe avec le code ASM dedans ^^
Encore une chose, j'ai laissé les déclarations des fonctions Search... dans FileSystem, elles ne sont pas faites, mais c'est prévu.
Dernière chose ==> je compte mettre plus tard (quand j'aurais le courage :p) la description de chaque fonction dans les attributs de procédure.
La question étant : en anglais ou en français ??
Enjoy, @+
27 avril 2007 à 21:43
Au menu :
1) suppression d'un tout petit bug qui empechait de récupérer
les infos de la classe PhysicalDisk
2) Changé la langue (c'est de l'anglais dans l'exemple, paske j'ai posté également cette source sur un site anglais)
3) Ajout de nombreuses fonctions, à savoir :
Dans FileSystem :
-FusionFiles (fusion de fichier découpés)
-CutFile (découpage de fichier)
-SetFileDates (pour changer les dates d'un fichier)
-SetFolderDates
-SetVolumeLabel (changer le label d'un disque)
-SanitizeFile
-SanitizeDrive
-SanitizePhysicalDisk
-CompareFiles (compare 2 fichiers)
-CreateIsoFromDrive (créé un fichier ISO depuis un disque)
Dans File :
-SetDates
-DriveName
-FolderName
-Sanitize
-CutFile
Dans Drive :
-Sanitize
-SetVolumeLabel
-CreateIso
Dans PhysicalDrive :
-Sanitize
Je n'ai pu tester SanitizeDrive et SanitizePhysicalDisk (la dernière est d'ailleurs nouvelle) car pas de disque sous la main, si quelqu'un pouvait confirmer le bon fonctionnement...
Merci, @+
26 avril 2007 à 22:50
Demain çà va coder sec ^^ (je vois déjà les 5000 lignes dans FileSystem.cls)
@+
26 avril 2007 à 22:42
26 avril 2007 à 22:22
Et au fait, devrais-je de ton avis ajouter les autres fonctions citées précédemment ?
@+
26 avril 2007 à 22:19
26 avril 2007 à 22:08
Sinon t'as raison, une interface sera beaucoup plus "sure" pour l'user. Bien que probablement plus lente ?
@+
26 avril 2007 à 22:03
Bref, j'arrete la sinon je vais m'auto-stresser.
Papa Renfield s'il vous plait :p
26 avril 2007 à 21:57
Devrais-je ajouter des fonctions du genre :
-découpage/fusion de fichier
-création d'un fichier ISO depuis un lecteur CD/DVD
-comparaison de fichiers
-...etc
?
@+
26 avril 2007 à 21:49
Mais quel est le problème avec le pointeur de fonction ? Ok c'est limité au VB6 (pas antérieur) avec AddressOf, mais çà tourne bien (comme CopyFileEx par exemple).
Cela étant, j'avoue que l'interface me semble carrément mieux ! Je vais en plus pouvoir mettre en application ce que m'a appris Renfield !
@+
26 avril 2007 à 21:42
26 avril 2007 à 21:38
lol pour "mavar = TextBox1" ;) Bien sur je l'ai déjà fait ^^ Mais c'est tellement laid que j'ai arrêté :p
Bon donc dans mon élan de folie, je rajoute la recherche multi-critères ??
(si oui, je suppose qu'il faut prévoir en param l'adresse d'une fonction de callback pour la progression ?)
Et je proposerai même les properties de date en écriture... puisqu'il faut être complet...
@+ (et merci Galain !!)
26 avril 2007 à 21:35
Me dit pas que t'as jamais fait :
mavar = TextBox1
:p
26 avril 2007 à 21:33
26 avril 2007 à 21:33
26 avril 2007 à 21:31
Mais faudra pas se plaindre si quelqu'un fait
Call FS.GetDrive("C").Sanitize :p
Au passage : sais tu comment cacher ta classe pour éviter que l'utilisateur la voit dans la liste de l'autocomplétion ?
Et pendant que j'y suis (^_^), quel est l'intérêt profond de définir une "Procédure par défaut" (mis à part pour le flemmard qui veut pas tapper ".Path") ??
@+ (donc pas de MAJ ce soir, mais demain !)
26 avril 2007 à 21:26
hahah faut que j'arrete la coke :p
26 avril 2007 à 21:21
Mais personne ne trouve dangereux de mettre la méthode "Sanitize" dans un objet Drive, PhysicalDisk ou File ????
@+
26 avril 2007 à 21:19
Pour Violent_Ken la valeur 1 en Currency est représentée sur 64 bits par la valeur 10000 équivalente en binaire : donc il faut diviser par 10000 pour retrouver la valeur binaire correcte 1 sur 64 bits et ensuite on multiplie cette valeur par Bytespersector pour avoir le pointeur sur le premier octet à lire ou écrire
Pour Eb : d'accord avec toi je l'ajouterai; cela ne mange pas de pain
A+ les gars
26 avril 2007 à 21:09
@+ (désolé pour le double post, vade retro tabulation)
26 avril 2007 à 21:08
C'est entre autres le fait qu'il faille rajouter une classe (que d'ailleurs je ne sais pas masquer pour l'utilisateur !) et quelques centaines de lignes pour la sanitization, les fonctions Friend prenant un param un pointeur...etc.
Puis "la" grosse question est : est-ce raisonnable de mettre ce bout de code somme toutes dangereux et d'une utilisation relativement rare dans une library qui a pour objectif de remplacer FSO "au quotidien" (enfin perso :p) ??
Peut être que oui en fait...je sais pas trop...
En disant "moi je l'ajouterais...." tu vas finir par me le faire mettre dedans ! lol
@+
26 avril 2007 à 21:00
J'en connais ils font des convertisseurs euro/franc avec 10x plus de code :p
Surtout pour un "FileSystem", moi je l'ajouterais...
26 avril 2007 à 20:58
Dsl pour ce triple post...
@+
26 avril 2007 à 20:56
Perso, j'ai : Pointeur = CCur(StartingSector) * CCur(BytesPerSector)
@+
26 avril 2007 à 20:53
"En faisant (P/10000) * B au de (P*B)/10000 on multiplie..." ==> exact... j'essaie de le prendre en compte dans mes codes pour éviter l'overflow, c'est une erreur de ne pas l'avoir mis !
Merci pour ce commentaire constructif.
Je vais faire une MAJ ce soir je pense (correction de bugs, optimisations et ajout de nouvelles fonctions).
us_30 ==> Finalement je ne mettrais pas la sanitization, car trop lourd à mon gout (ASM de EB...etc).
@+
26 avril 2007 à 00:07
Tu as écrit : "J'ai aussi changé la fonction GetLargeInteger et l'est remplacée par une version avec CopyMemory que m'a fournie Galain ==> elle est trois fois plus rapide qu'avant."
Ca c'est une bonne nouvelle
Mais on peut aller plus vite
Dans un module on déclare
Public Part32(0 to 1 ) as long ' 2 Long 32 bits
ensuite inspire toi de ma Sub d'accès direct disque
Public Sub DirectReadWrite(ByVal iStartSec As Currency, ByVal nbytes As Long, accesrw As Byte)
' Attention le nombre d'octets lus ou écrits ainsi que l'offset du premier octet lu ou écrit
' doivent impérativement être un multiple de la taille d'un secteur de disque
' Istartsec et nbytes doivent être des multiples de 512 ( taille standard des secteurs des disques)
Dim Bytesread As Long
Dim Byteswrite As Long
Dim ret As Long
On Error GoTo dskerror
dskerr = False
If hDevice& <> 0 Then CloseHandle hDevice&
'ouvre le drive
hDevice& = CreateFile(ldrive$, GENERIC_READ Or GENERIC_WRITE, FILE_SHARE_READ Or FILE_SHARE_WRITE, 0&, OPEN_EXISTING, 0&, 0&)
'quitte si le handle n'est pas valide
If hDevice& INVALID_HANDLE_VALUE Then dskerr True: Exit Sub
'move pointer
pointeur = (CCur(iStartSec) / 10000) * CCur(BytesPerSector) ' VOIR NOTE
' transforme un Currency en 2 Long signés 32 bits
CopyMemory Part32(0), pointeur, 8 ' Pointeur -----> Part32(0) et Part32(1)
ret& = SetFilePointer(hDevice, Part32(0), Part32(1), FILE_BEGIN)
If ret& = -1 Then GoTo dskerror
Select Case accesrw
Case 0 ' lecture
'redimensionne les tableaux résultants
ReDim readoctet(0 To nbytes& - 1)
'appel l'API de lecture
ret& = ReadFile(hDevice, readoctet(0), nbytes&, Bytesread&, 0&)
If ret& = 0 Then GoTo dskerror
Case 1 ' écriture
' verrouilage de la zone du disque à écrire
Call LockFile(hDevice&, Part32(0), Part32(1), nbytes&, 0)
' écriture disque
ret& = WriteFile(hDevice&, writeoctet(0), nbytes&, Byteswrite&, 0)
' on vide les buffers internes et on dévérouille la zone
Call FlushFileBuffers(hDevice&)
Call UnlockFile(hDevice&, Part32(0), Part32(1), nbytes&, 0)
End Select
'ferme le handle
CloseHandle hDevice
Exit Sub
dskerror:
dskerr = True
CloseHandle hDevice
End Sub
Ainsi on évite 2 Copymemory et j'espère que le temps gagné n'est pas gaché par l'accès à 2 variables tableau
Autre chose : Garder la syntaxe de la ligne car ainsi on multiplie l'étendue des secteurs accessibles
Soit P Pointeur et B Bytespersector
En faisant (P/10000) * B au de (P*B)/10000 on multiplie l'étendue des secteurs accessibles par B : on divise d'abord et on multiplie ensuite
Mais les limites du type Currency sont encore loin d'être atteinte : il nous faudrait des disques durs énormes pour les dépasser (922 337 203 685 477 octets pour être précis : valeur entière max d'un Currency positif)
A + et bravo pour tes codes
25 avril 2007 à 13:06
Sinon, effectivement, la recherche de fichiers/dossiers n'est pas inclue, il n'y a qu'un listing des fichiers/dossiers qui est possible.
Pour l'utilitaire d'effacement des fichiers, j'avais pensé à l'inclure, mais je me suis dit que çà allourdirait quelque peu la classe pour une utilisation au finale assez rare.
Je vais y réfléchir, voir si c'est pas trop lourd à inclure, mais déjà merci pour ces propositions ! (et merci également pour avoir signalé le bug que je corrigerai ce soir).
@+
25 avril 2007 à 00:28
24 avril 2007 à 23:29
J'ai pas trop résisté, j'ai jetté un petit coup d'oeil, tout de même... Pour l'instant j'ai vu qu'une simple coquille dans info lecteur, pour le calcul en pourcentage de libre. Cela renvoi le pourcentage occupé à la place... ah ! -);
Sinon, en présentation tu demandes aussi des idées de fonction... Il me semble (sauf erreur) que tu n'as pas de fonction de recherche de fichier, de dossier, avec le critère nom ou avec le contenu, comme dans l'exploreur... voir avec n'importe quel critère (ou presque) par exemple, la date de création, d'accès, etc... enfin, bon on peut aller loin comme ça... voir en combinaison de critères (multi-critères). Exemple, avec la date de création et contenant tel info... Long programme...
Il y a pas longtemps, il me semble également que tu avais codé un "Broyeur de fichier", je ne crois pas l'avoir vu dedans. A rajouter si c'est bien le cas, enfin c'est une idée.
A noter, que j'avais fait également une fonction similaire (peut-être encore plus élaborée, mais qu'en VB donc beaucoup moins rapide) pour effacer toute trace d'un fichier, certes, mais il me sert après un cryptage de fichier. En effet, il est un peu bête de crypter un fichier, si sa forme non cryptée est seulement effacé par un simple DELETE... De plus, pour des fichiers déjà éffacés (delete), il est intéressant de pouvoir aussi "broyer" leurs traces. Donc, j'avais aussi codé un remplissage jusqu'à saturation du disque, (avant effacement). Après essai par plusieurs programmes de type FileRecovery, on peut constater qu'ils ne peuvent plus rien retrouver... donc, voici une idée... mais bon, c'est très spécifique, j'en conviens... De plus dans le volume où windows garde son fichier d'échange, on ne peut pas tout faire... voir si on peut faire mieux...
Voilà, déjà...
Amicalement,
Us.
PS : EBArtSoft : On peut aussi avoir petit et rapide...
24 avril 2007 à 22:50
EB ==> Bah, l'important c'est que çà tourne vite ^^ D'ailleurs avec le CreateFile unique, c'est plutôt pas trop mal (en tout cas comparé à avant...)
Madm@tt ==> L'API EncryptFile/DecryptFile ^^
http://msdn2.microsoft.com/en-us/library/aa364021.aspx
C'est le cryptage fourni par Windows (clic droit dans explorer, propriétés, avancé, crypter).
Comme c'était pas vraiment le propos de cette source, j'ai fait (très) simple :p
Les 5 dernièrs fonctions ne sont que 5 appels à des APIs ;)
@+
24 avril 2007 à 22:25
Pour les fonctions d'encryption tu utilise quel système de cryptage ?
24 avril 2007 à 22:15
Je veux que ce soit rapide !
ou
Je veux que ce soit petit !
Enncore une fois je le redis... sympa :p
24 avril 2007 à 21:38
Impresionnant ! Je regarderai en détail ce week-end. Bravo 10/10 !
Amicalement,
Us.
24 avril 2007 à 19:42
- EncryptFile
- EncryptFolder
- DecryptFile
- DecryptFolder
- DownloadFile
@+
24 avril 2007 à 16:03
@+
24 avril 2007 à 15:54
Je change çà de suite !
@+
24 avril 2007 à 15:51
24 avril 2007 à 15:17
24 avril 2007 à 15:14
- suppression de certains enum en double
- suppression de la classe clsDef qui était VRAIMENT inutile
- suppression des déclarations de constantes et de variables inutiles
- suppression d'un bug énorme dans GetDriveVolumeInformation_HANDLE ==> retour à la version son _HANDLE ==> "seulement" un gain de 65% de temps par rapport à la version 1
@+
24 avril 2007 à 14:56
Par rapport à la précédente version :
- gain sur la fonction GetFile : 10% de temps en moins
- gain sur la fonction GetPhysicalDisk : 30 % de temps en moins
- gain sur la fonction GetFolder : 40 % de temps en moins
- gain sur la fonction GetDrive : 80% de temps en moins (oui je sais... !!)
Par contre j'ai du rajouter 600 lignes de code...
J'ai aussi changé la fonction GetLargeInteger et l'est remplacée par une version avec CopyMemory que m'a fournie Galain ==> elle est trois fois plus rapide qu'avant.
J'ai aussi rajouté un CloseHandle qui manquait dans GetPhysicalDiskName.
Voilà, çà commence a être vraiment rapide !
@+ (je regarde les typelibs)
23 avril 2007 à 20:45
Merci, @+
23 avril 2007 à 19:58
bah crée une typlib ! ou ajoute les enum dans une autre classe...
23 avril 2007 à 19:55
@+
23 avril 2007 à 19:41
23 avril 2007 à 19:10
Alors le meilleur compromis serait-il de faire :
- CreateFile une fois lors du RefreshInfos de la classe Drive
- récupérer les infos par des fonctions Friend de FileSystem avec le handle en param
- CloseHandle à la fin de la sub RefreshInfo
?
Autre chose pendant que je t'ai sous la main ^^ ==> sais tu comment cacher la classe clsDef pour le projet utilisant la dll ?
Merci, @+
23 avril 2007 à 19:06
Non je voulais dire que si tu temporise toute les variables pour accelerer l'acces aux proprietes tu va te retrouver avec des disque qui n'existe plus. Je prends comme exemple une clef usb que l'on retire
:p
23 avril 2007 à 19:02
@+
23 avril 2007 à 18:55
:p
23 avril 2007 à 18:33
Effectivement, c'est plus logique que les properties ne récupèrent pas elles-même les infos (enfin je crois) ! Laissons çà aux functions ^^
Par contre, gros problème encore avec les Drives/Disks. J'espère que c'est l'appel à CreateFile() pour récupérer le handle du drive qui est très lent, parce que sinon je vois pas trop comment optimiser...
A ton avis, est ce grave d'avoir un handle du disque "ouvert" durant toute la vie d'une variable de type Drive ou PhysicalDisk ??
Parce si c'est pas grave, je récupère une seule fois le handle dans le Class_Initialize du Drive/PhysicalDisk, je le stocke en private (et éventuellement je le propose en Property Get) et ensuite j'appelle des fonctions déclarées en Friend dans FileSystem avec comme paramètre le handle du disque ==> gain de 5 ou 6 appel à l'API CreateFile par GetDrive.
A ton avis, c'est une bonne idée ou pas ??
@+
23 avril 2007 à 18:24
23 avril 2007 à 18:20
Par contre elle est beaucoup, beaucoup plus lente sur les accès aux infos sur les disques... Je vais essayer de réparer un peu çà en ne récupérant qu'une seule fois le handle avec CreateFile.
Mais je crains que l'écart de temps sur les disques demeure vraiment élevé...
@+
23 avril 2007 à 18:06
En faisant 500 fois :
FSO.GetFile().Size
FSO.GetFile().DateCreated
.... (10 infos)
et
maclasse.GetFileSizes().FileSize
maclasse.GetFileDates.DateCreated
.... (10 infos)
ma classe est TROIS FOIS plus rapide que FSO.
En conclusion :
- cette source est bien plus rapide que FSO
- si on veut récupérer qu'une info (exemple les attributs), on fera "maclasse.GetFileAttributes(file)" et non "maclasse.GetFile(file).Attributes" (qui récupère toutes les infos)
- si on veut récupérer toutes les infos sur un fichier, on fera "set cFile=maclasse.GetFile(file) puis info=cFile.PROPERTY"...etc
Je vérifie que c'est pareil avec les classes Folder et Drive...
@+
23 avril 2007 à 17:58
Je viens faire le test de récupération des infos sur un fichier avec FSO vs cette source...
Pour la récupération de 500*22 infos, ma source est plus rapide de 50%... Et en plus, quand on fait .GetFile avec cette source, on récupère BEAUCOUP PLUS d'infos qu'avec le GetFile de FSO....
Autrement dit cette source est vraiment plus rapide, même si effectivement un bête ".GetFile().Size" sera plus rapide avec FSO (car ne récupère que la Size avec FSO, et récupère tout avec ma source).
Pas sur d'être très clair...
Je fait les tests avec les classes Drive et Folder...
@+
23 avril 2007 à 17:53
Mais c'est mieux comme ça, car si tu accède 2 fois de suite à la propriété il la met à jour 2 fois c'est bete, et en plus c'est une propriété, pas une fonction, donc une propriété dans la logique, c'est qqch de fixe que l'ont récupère, alors que la fonction sous-entend un traitement pour la trouver (enfin c'est comme ça que je voit les choses du haut de ma chaise), mais y'a surement d'autres points de vue ^^
Sinon effectivement 200 ms c'est mieux que 1,5s
23 avril 2007 à 17:48
J'ai refait quelques tests : GetDrive ne met aujourd'hui plus que 200ms... je vois pas du tout pourquoi hier c'était 1500 ??
Et de plus, quand on fait un GetFile, un GetDrive ou un GetFolder avec FSO, AUCUNE info n'est récupérée...c'est quand on fait GetFile().PROPERTY que l'info est récupérée !
Donc normal que ce soit beaucoup plus rapide...puisque çà ne récupère pas d'infos !!
Je vais faire des benchs comparatifs réels d'obtention d'infos entre FSO et cette source.
@+
22 avril 2007 à 21:17
22 avril 2007 à 17:17
22 avril 2007 à 16:04
Carrément plus rapide comme méthode...
@+
22 avril 2007 à 16:01
Enfin le problème c'est que ce n'est pas assez rapide.
L'appel à GetDrive() pour mon HDD contenant Windows met... 1.5 secondes !!
Bon ok, toutes les infos sont récupérées mais quand même, ce temps est énorme !
De même pour les fichiers, 500 fois GetFile() met quand même 800 ms... beaucoup plus que FSO.
Y a moyen d'optimiser en ne récupérant qu'une seule fois le handle des objets, mais par contre faudrait mettre plusieurs fonctions/APIs/ENUM dans les objets...
@+
22 avril 2007 à 15:50
Sinon il faut pas se fier à l'aperçu du contenu du zip, chez moi il affiche que la dll mais en téléchargant on tombe bien sur le zip complet
22 avril 2007 à 15:12
Donc si vous avez LA MOINDRE IDEE POUR OPTIMISER CE CODE, merci d'en m'en faire part !
Merci, @+ ;)