The progressbar only reaches about 77% in the unHacked code. It never
reaches 100%!
Bill
// Hack Fix
procedure TForm32.Button1Click( Sender: TObject );
var
I: Integer;
begin
Button1.Enabled := False;
Button2.Enabled := False;
for I := 1 to 100 do
begin
ProgressBar1.Position := I + 8;
Application.ProcessMessages;
Sleep( 75 );
end;
ProgressBar1.Position := 0;
Button1.Enabled := True;
Button2.Enabled := True;
end;
// unHacked
procedure TForm32.Button2Click( Sender: TObject );
var
I: Integer;
begin
Button1.Enabled := False;
Button2.Enabled := False;
for I := 1 to 100 do
begin
ProgressBar1.Position := I;
Application.ProcessMessages;
Sleep( 75 );
end;
ProgressBar1.Position := 0;
Button1.Enabled := True;
Button2.Enabled := True;
end;
Bill
> The progressbar only reaches about 77% in the unHacked code. It never
> reaches 100%!
This is because the progress bar in Vista animates to the next position.
Is this in QC? If not I wouldn't hold out for a "fix". You could also
just sleep longer at the end to give the animation time to finish.
So I assume TGauge from the examples tab doesn't have those problems?
Greetings
Markus
Really, I just tried it and it works for me- or at least it does what I
expected it to: progress bar goes to the end and then goes back to 0.
I'm using BDS 2006 though so is this only a Vista thing?
Cheers,
Kevin.
Jeez... I meant "is this only a Delphi 2007 and later thing?"
As far as I know, this is only an issue with Windows Vista.
There are in fact two issues:
- The one given by Nathanial, and
- The progress bar flickering.
The latter can easily be fixed (in ComCtrls.pas) by handling in the message
WM_ERASEBKGND in TProgressBar and calling "DefaultHandler" in that handler.
The former can also be fixed, but it's a bit of a hack. First, you need,
internally, to hard code the maximum position to Limit16. Second, whenever
the position of the progress bar is to be set, you have to make the two
following calls:
SendMessage(Handle, PBM_SETPOS, Val, 0);
SendMessage(Handle, PBM_SETPOS, Val-1, 0);
With Val, the value of the position of the progress bar. The second call
will ensure that Windows Vista doesn't do the animation and will get the
progress bar to reach its position (minus 1) straight away. The -1 is fine,
since we internally hard coded the maximum position to Limit16 (Limit16,
because that's what seems to be required -- can't recall where I saw that in
the source code).
That's about it regarding the general idea, though the implementation
requires a bit more work...
Alan.