Discussion :

[NicCo]

Bonjour,
Je suis à la recherche d'un composant ou d'un ensemble de composant permettant de calculer des hash MD5 (et autres hashs plus évolués) sous Delphi XE2.
J'ai trouvé DCPCrypt qui marche sans problème à l'exception d'une chose : impossible d'afficher une barre de progression durant le calcul du hash...
Si quelqu'un sait comment afficher ceci je suis preneur, avec ce composant ou un autre.
Merci !

[Barbibulle]

Lancez le calcul dans un thread et pendant ce temps affichez une animation d'attente (les barres de progression qui bouclent qui sont utilisés quand on a un traitement dont on ne connait pas le temps ni la progression).

Sinon en composant il existe LockBox http://sourceforge.net/projects/tplockbox/

Il me semble qu'avec Indy on peut également calculer le Hash MD5 d'un stream (donc en utilisant un TfileStream on peut facilement récupérer le hash MD5)

En payant il y les composants dédiés sécurité de chez Eldos qui doivent le faire. Mais ca fait cher si vous n'avez besoin que du HashMD5...

Sinon on trouve des unités delphi avec les sources de l’algorithme HASH MD5 libre à vous le modifier les sources (enfin sous réserve que la licence vous l'autorise) pour y insérer la notion de progression...

[NicCo]

Merci pour les infos.
Concernant le hash MD5, DCPcypt semble très bien fonctionner (avec un TFileStream pour la gestion du fichier).
Le point bloquant est l'absence d'indication de la progression du hash pour les gros fichiers. J'ai essayé de bricoler un peu les sources pour y adapter une ProgressBar mais rien de concret pour le moment...

[Paul TOTH]

Merci pour les infos.
Concernant le hash MD5, DCPcypt semble très bien fonctionner (avec un TFileStream pour la gestion du fichier).
Le point bloquant est l'absence d'indication de la progression du hash pour les gros fichiers. J'ai essayé de bricoler un peu les sources pour y adapter une ProgressBar mais rien de concret pour le moment...

la progression étant liée à la lecture de fichier, il doit être possible de dériver TFileStream pour y intégrer la gestion de la progression, en surchargeant la fonction Read probablement.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
type
  TProgressFileStream = class(TFileStream)
  private
    FOnProgress: TNotifyEvent;
  public
    function Read(var Buffer: TBytes; Count: Longint o): Longint; override;
    property FOnProgress: TNotifyEvent read FOnProgress write FOnProgress;
  end;
 
procedure TProgressFileStream.Read(var Buffer: TBytes; Count: Longint): Longint; 
begin
  inherited;
  if Assigned(FOnProgress) then
   FOnProgress(Self);
end;

évidemment si le code lit le fichier par paquet, la progression sera éventuellement saccadée.

[NicCo]

Merci pour cet exemple de code, je vais le tester
Par contre tu spécifies comment la progressbar que tu veux utiliser ? La saccade n'est pas un problème au cas où.

[Barbibulle]

Il faut que tu crées une procédure :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Private
  procedure GestionProgressBar(Sender: TObject);

Après la création de ton TProgressFileStream il faut que tu assignes GestionProcessBar à la propriété FOnProgress.

Et c'est donc dans ta procédure GestionProgressBar que tu vas devoir gérer la progression de ta barre. A chaque Read du stream GestionProgressBar sera appelé.

[NicCo]

Ok merci je vais regarder ca.
J'ai déjà des problèmes avec le code de Paul TOTH que je vais essayer de corriger, il y a des erreurs de syntaxe je pense ?

[Paul TOTH]

Ok merci je vais regarder ca.
J'ai déjà des problèmes avec le code de Paul TOTH que je vais essayer de corriger, il y a des erreurs de syntaxe je pense ?

à par le "o" en trop qui s'est glissé dans le code je ne vois pas

[NicCo]

à par le "o" en trop qui s'est glissé dans le code je ne vois pas

J'ai une erreur de syntaxe sur la ligne suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

property FOnProgress: TNotifyEvent read FOnProgress write FOnProgress;

Qui semble être acceptée quand je change en :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

property OnProgress: TNotifyEvent read FOnProgress write FOnProgress;

Il y a aussi je pense la déclaration d'une Procedure au lieu d'une Function pour la fonction TProgressFileStream.Read(...)

Et la procédure Read ne semble pas être acceptée, je ne sais pas pourquoi j'ai une erreur "La déclaration de 'Read' diffère de la déclaration précédente." et un "Types incompatibles" pour le "inherited" qui est dans la fonction Read.

J'avoue aussi ne pas trop savoir comment faire pour assigner une procédure à une propriété

[Barbibulle]

A mon avis le read a été changé dans les versions plus récentes de Delphi
essayez :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
  TProgressFileStream = class(TFileStream)
  private
    FOnProgress: TNotifyEvent;
  public
    function Read(var Buffer; Count: Longint): Longint; override;
    property OnProgress: TNotifyEvent read FOnProgress write FOnProgress;
  end;

[NicCo]

A mon avis le read a été changé dans les versions plus récentes de Delphi
essayez :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
  TProgressFileStream = class(TFileStream)
  private
    FOnProgress: TNotifyEvent;
  public
    function Read(var Buffer; Count: Longint): Longint; override;
    property OnProgress: TNotifyEvent read FOnProgress write FOnProgress;
  end;

Merci ! Avec cette modification, je n'ai plus d'erreur de compilation. Il me reste à savoir comment assigner une fonction à une propriété... Le Read me renverra la position de la lecture dans le fichier ?

[Barbibulle]

Exemple complet sous D7 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
unit Unit1;
 
interface
 
uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, ComCtrls, StdCtrls;
 
type
  TProgressFileStream = class(TFileStream)
  private
    FOnProgress: TNotifyEvent;
  public
    function Read(var Buffer; Count: Longint): Longint; override;
    //function Read(var Buffer: TBytes; Count: Longint): Longint; override;
    property OnProgress: TNotifyEvent read FOnProgress write FOnProgress;
  end;
 
  TForm1 = class(TForm)
    Button1: TButton;
    ProgressBar1: TProgressBar;
    procedure Button1Click(Sender: TObject);
  private
    MonFichier : TProgressFileStream;
  public
    procedure GestionProgressBar(Sender: TObject);
  end;
 
 
var
  Form1: TForm1;
 
implementation
 
{$R *.dfm}
 
{ TProgressFileStream }
 
function TProgressFileStream.Read(var Buffer; Count: Integer): Longint;
begin
  result := inherited Read(Buffer, Count);
  if Assigned(FOnProgress) then
    FOnProgress(Self);
end;
 
{ TForm1 }
 
procedure TForm1.GestionProgressBar(Sender: TObject);
begin
  // traitement de ma barre
  ProgressBar1.Position := MonFichier.Position;
end;
 
procedure TForm1.Button1Click(Sender: TObject);
var buffer :array[1..2000] of Byte;
begin
  MonFichier := TProgressFileStream.Create('C:\Archivage\DisqueF.zip', fmOpenRead or fmShareDenyWrite);
  try
    MonFichier.OnProgress := GestionProgressBar;
    ProgressBar1.Max := MonFichier.Size;
 
    // Remplacer la boucle While ci dessous par l'appel de la fonction de calculMD5 en passant MonFichier en paramètre
    while MonFichier.Position < MonFichier.size do
    begin
      MonFichier.Read(Buffer, sizeof(Buffer));
    end;
 
  finally
    MonFichier.Free;
  end;
 
end;
 
end.

[NicCo]

C'est parfait ça fonctionne !
Comme l'avait prévu Paul TOTH, la progression est saccadée car j'ai un buffer de 8192. Même si on dépasse un peu le sujet de base qui est maintenant résolu, y a-t-il des recommandations sur le choix de la taille du buffer pour des petits et/ou des gros fichiers ? Un petit buffer doit entraîner des accès plus fréquents au fichier mais consommer moins de RAM, un gros buffer l'inverse ?

[Barbibulle]

La RAM ce n'est en règle générale pas un problème.
Par contre ce qu'il faut comprendre c'est que les accès disque sont beaucoup plus lent qu'en RAM.

Lire un gros fichier octet par octet va prendre énormément plus de temps que de le lire par bloc de plusieurs milliers d'octets.

[NicCo]

Donc il vaut mieux avoir un gros buffer pour réduire le temps de lecture d'un fichier, ce qui entraînera une saccade encore plus grosse au niveau de la ProgressBar

[Barbibulle]

Et bien tout dépend de ce qui est important, la vitesse ou le visuel.

Après rien ne vous empêche de prendre un gros buffer pour les gros fichier et un petit buffer pour les petit fichier.

Genre vous prenez la taille de votre fichier puis pour divisez par 20 pour vous donner la taille du buffer (il y aura donc au moins 20 lectures et donc 20 positions différente sur votre progressbar)

Une fois divisé par 20 pour pouvez aussi définir une taille de buffer mini et maxi. (la taille mini entrainera plus de saccade pour ces petits fichiers mais sera rapide, la taille maxi vous évitera d'avoir un buffer qui mange toute la mémoire :p ).

Si votre traitement c'est pour des lots de fichiers vous pouvez avoir une barre de progression pour les fichiers (de 1 au nombre de fichier) et une seconde pour la lecture de vos fichiers (a mon avis ici ce n'est pas très gênant que ça saccade).

Si votre traitement c'est juste pour le calcul de MD5 d'un seul fichier vous pouvez ajuster le buffer pour avoir une barre de progression plus fluide.

[NicCo]

Effectivement il va falloir que je choisisse un compromis entre le fond et la forme

Merci beaucoup pour toutes ces infos, ce fut d'une grande aide !

[Barbibulle]

Pour aller plus loin dans le raisonnement, je me poserai la question de l'utilité d'une barre de progression si le fichier est petit. Le traitement doit être rapide...Et donc je dirais que l'affichage d'une barre ralenti le traitement :p

Enfin à vous de faire des tests.

N'oubliez pas de marquer le post [Résolu] avec le bouton dédié en bas.

[NicCo]

Tout à fait d'accord pour la barre de progression , mais je compte majoritairement travailler avec des fichiers de plus de 1Go d'où l'utilité de la barre de progression

Merci encore !

[ShaiLeTroll]

Pour des traitements de plusieurs minutes avec Max défini,
soit j'affiche tous les 256 éléments traités ou via GetTickCount, je ne change le barre de progession que si la dernier changement était de moins de 500 ms (ça suffit pour que l'utilisateur voit que cela avance)
sur un traitement d'un million de lignes générant chacune 100 SQL, ça dure tellement longtemps que :
- personne ne reste devant à regarder la barre de progression pendant 2heures
- deux refresh par seconde, ça va pas couter cher pour un si long traitement

si la barre de progression est fausse car on ne peut pas prédire le temps, genre un SQL compliqué,
j'avance de +1 toutes les 25ms, ça donne une illusion parfaite de progression (une fois à 100 retour à 0)

Voici un code avec un mélange,
Ce gestionnaire gère la progression de plusieurs taches pouvant être lancé depuis le même écran, certaines bien défini, d'autre non prédictible
la pbProgress à un max défini (un nombre d'étape à suivre avec un APosition et ACount supérieur à Zéro) = tous les 256 Position + dessin forcé
la pbProgress n'a pas de max défini (on est justement en train de le chercher, APosition à -1 et ACount soit à 0 soit > 0) = tous les 25 ms et 256 position pour le label + dessin forcé
Plus toutes les 5 secondes, un ProcessMessage pour éviter que Windows passe la fenêtre en "Ne répond pas"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
//------------------------------------------------------------------------------
procedure TModuleBiduleForm.ProgressEventHandler(Sender: TObject; APosition: Integer; ACount: Integer);
begin
  if Assigned(FPatience) then
  begin
    if (0 <= APosition) and (APosition <= ACount) then
    begin
      if not ByteBool(APosition) then // tous les 256 !
      begin
        pbProgress.Position := APosition;
        pbProgress.Max := ACount;
        pbProgress.Refresh();
        TSlitePatience.ChangeMessage(FPatience, Format('Patientez ... %d / %d lignes traitées', [APosition, ACount]));
      end;
    end
    else
    begin
      // La progression à la volée (Flighty) n'est pas prédéterminé, on donne juste l'illusion de traitement
      // On ne simule cette progression qu'à un interval régulier pour avoir une fausse progression fluide
      if (GetTickCount() - FTickFlighty) > PROGRESS_FLIGTHY_TICK_DELAY then
      begin
        if pbProgress.Position >= pbProgress.Max then
          pbProgress.Position := 0
        else
          pbProgress.StepBy(1);
        pbProgress.Refresh();
        FTickFlighty := GetTickCount();
      end;
 
      if ACount = 0 then
        TSlitePatience.ChangeMessage(FPatience, 'Patientez ... ')
      else
        if not ByteBool(ACount) then
          TSlitePatience.ChangeMessage(FPatience, Format('Patientez ... %d lignes trouvées', [ACount]));
    end;
 
    if (GetTickCount() - FTickProcessMessages) > 5000 then
    begin
      Application.ProcessMessages();
      FTickProcessMessages := GetTickCount();
    end;
  end;
end;