[DEC] MD5 Hash großer Datei berechnen ohne Programhänger

[dominikkv]

Delphi-Quellcode:

  HashHelper1:=THash_Helper.Create;
  pack.MD5_Hash:=THash_MD5.CalcStream(data,data.size,TFormat_HEX,HashHelper1);
  freeandnil(HashHelper1);

ähm... bin mir zwar jetzt nicht sicher, aber ist es nicht so dass man HashHelper1 nicht freigibt weil die Klasse von TInterfacedObject abgeleitet ist und diese einen Referenzzähler hat und wenn der 0 ist sich die Klasse selber frei gibt?

[DGL-luke]

@alleinherscher:
"Zwei Vorfahren in einer Deklaration":

Das ist sogenannte Mehrfachvererbung. Die gibt es in Delphi aber gar nicht. Delphi kann aber (OLE-)Interfaces.
Wenn du darüber mehr wissen willst, solltest du genug finden unter dem Stichwort Interface.

Grob gesagt, beschreibt aber ein Interface was eine Klasse können muss. Um ein Objekt zu benutzen, benötigt man dann nur das Interface und nicht die tatsächliche Klasse, denn das Interface stellt sicher, dass das Objekt alles kann was man braucht.

[Dax]

Zitat:

Zitat von dominikkv

ähm... bin mir zwar jetzt nicht sicher, aber ist es nicht so dass man HashHelper1 nicht freigibt weil die Klasse von TInterfacedObject abgeleitet ist und diese einen Referenzzähler hat und wenn der 0 ist sich die Klasse selber frei gibt?

Ja, aber selbst freigeben kann man trotzdem. Man muss es sogar, wenn man nicht das Interface, sondern das Objekt benutzt (IInterface vs TInterfacedObject).

[alleinherrscher]

Danke Leute, ich werd mir dazu mal was durchlesen :)

[negaH]

Hi

man kann das mit der Hash-Helper Klasse so machen, aber empfehlen würde ich es nicht. Das IDECProgess Interface, obwohl so einfach konstruiert, ermöglicht uns noch viel mehr. 1.) Anwendung nicht einfrieren lassen, 2.) Fortschrittsbalken anzeigen, 3.) aktuelle Aktion kann durch Benutzer sauber abgebrochen werden.
Alle diee 3 Features sind Bestandteile des GUIs einer Anwendung, also sollte man diese Feasture auch darin einbauen, statt separate Klassen zu entwerfen. Denn diese bedeuten nur einen Umweg in der Programmierung, also eher ineffektiv.

Die normale Anwendung sieht so aus

Delphi-Quellcode:

type
  TForm1 = class(TForm, IDECProgress)
  public
    ProgressBar1: TProgressBar;
    procedure ButtonClick(Sender: TObject);
    procedure FormCloseQuery(Sender: TObject; var CanClose: Boolean);
  private
    FAction: Integer;
    FTick: Cardinal;
    procedure Process(const Min,Max,Pos: Int64); stdcall;
  end;


procedure TForm1.ButtonClick(Sender: TObject);
begin
  if FAction = 0 then
  try
    Inc(FAction);
    FTick := GetTickCount;
    Button.Caption := 'Abort';
    try
      with TCipher_Blowfish.Create do
      try
        Init(...);
        EncodeFile(FileName, FileName, Self);
      finally
        Free;
      end;
    except
      on E: Exception do
        if E is EAbort then ShowMessage('aborted by User')
          else reraise;
    end;
  finally
    FAction := 0;
    Button.Caption := 'Start';
  end else Inc(FAction);
end;

procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
  CanClose := FAction = 0;
  if not CanClose then Inc(FAction);
end;

procedure TForm1.Process(const Min,Max,Pos: Int64);
var
  Tick: Cardinal;
begin
// Fortschrittsbalken
  ProgressBar1.Min := 0;
  ProgressBar1.Max := 100;
  ProgressBar1.Position := Round((Pos - Min) / (Max - Min) * 100); // Anzeige in Prozent
// Antifreeze
  Tick := GetTickCount;
  if FTick + 100 <= Tick then
  begin // nur alle 100ms soll Application.ProcessMessages aufgerufen werden
    FTick := Tick;
    Application.ProcessMessages;
  end;
// Userabbruch
  if FAction > 1 then 
    Abort;
end;

Normalerweise ist es doch so: Ein GUI wird durch Anwender bedient. Das GUI -> TForm -> hat also eine ButtonClick() die die eigentliche längerandauernde Funktion startet. Dem Anwender ist es volkommen ausreichend wenn er zwei Dinge nun parallel machen kann, 1.) er kann die Aktion noch abbrechen, 2.) er kann weiterhin die Anwendung verkleinernen um an sein Onlinegame ranzukommen. Wir müssen also garnicht mit echter Parallelität programmieren, also ohne Threads. Obiger Source zeigt wie mit wenigen Griffen, direkt im GUI-Programmteil, die wichtigen 3 Forderungen erfüllt werden.
Man sieht auch sehr gut wie nun die Elemente des GUIs benutzt werden, ergo: IDECProgress ist ein Element des GUIs und gehört am besten direkt ins TForm statt in eigene Klasse die dann erst das GUI steuert (quasi doppelt gemoppelt).

Die Standardvorgehensweise beim IDECProgress in eigenen Klassen die DECs Objekte benutzten wäre also so das man den Parameter Progress: IDECProgress durchschleift bis zum GUI Programteil.


Gruß Hagen