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