Progress bar stops at 3/4 even if Position=4 and Max=4. Delphi

Question

I know it's not the known animation problem because the bar is already set to pbsPaused and SmoothReverse is true. The bar is called by a function which sends files over ftp. It looks like this:

function sendLists(FTP: TIdftp; cBox: TComboBox): Boolean; Overload; // this sends ALL     lists from combobox to ftp server
var
i, k: Integer;
idList, resList, filesList: TStringList;
begin
Result:=TRUE;
resList:=TStringList.Create;
filesList:=TStringList.Create;

progress.fmBar.Init(filesList, 0, filesList.Count, 1);// this initiates the bar (files, min, max, step)
for i := 0 to cBox.Items.Count-1 do //comboBox has 4 items in
    begin
        for k := 0 to idList.Count-1 do
        begin
            if (something is true)  then
            resList.Add(idList[k]);
        end;
    resList.SaveToFile('temp.dat');
    resList.Clear;

    progress.fmBar.StepBar;//this should be called 4 times
    FTP.Put('temp.dat', cBox.Items[i]+'-List.dat'); //the 4 files are sent successfully so that confirms 4 passes are being done.

    end;
resList.Free;
filesList.Free;
FTP.Disconnect;
end;

And StepBar like this:

procedure Tfmbar.StepBar;
begin
pbMain.StepIt;
if pbMain.Position=pbMain.Max then btOk.Enabled:=TRUE;
pbMain.Update;
fmBar.Update;
end;

The labels correctly shows 100%, and I've tested the pbMain.Position and pbMain.Max both shows 4, which is in this case the number of files to send. I used this same function in another task and it updates perfectly. Maybe I'm missing something?

http://stackoverflow.com/questions/6128287/tprogressbar-never-fills-up-all-the-way-seems-to-be-updating-too-fast http://stackoverflow.com/questions/6071626/progressbar-is-slow-in-windows-forms etc. — David Heffernan, Oct 25 '13 at 19:38
@DavidHeffernan I've already tried those and they don't work. — Gab, Oct 25 '13 at 20:01
I guess your computer is broken, because that technique has been shown to work everywhere else. Perhaps your program is at fault. — David Heffernan, Oct 25 '13 at 20:03
Your comment said that the answers at those questions don't work. They've been shown to work again and again. Perhaps you could supply an SSCCE so that all doubt was removed. May take a little effort on your part. — David Heffernan, Oct 25 '13 at 20:08
I was talking about the post itself. I said this is not the animation bug because I already fixed it and the bar works perfectly with other tasks. Of course my program is at fault that's why I'm here for. — Gab, Oct 25 '13 at 20:10
"The known animation bug" is imprecise. There is no bug. The behaviour is as designed. Time for an SSCCE. — David Heffernan, Oct 25 '13 at 20:11
As said again, the term was not bug but problem. If it was imprecise, you seemed very familiar with it. I'll provide that SSCCE — Gab, Oct 25 '13 at 20:18
Well, I can't seem to reproduce it. So that means something is wrong in my code. But what I can't undertsand is why it works with all other tasks except this one. — Gab, Oct 25 '13 at 20:25
This is why you need to post an SSCCE. Take a look at your post. Did you read what you wrote? ;-) 95% of it has nothing to do with progress bar controls. Why is that stuff event there? Write a 20 line SSCCE about the progress bar and then it's game on. — David Heffernan, Oct 25 '13 at 20:26
I can't reproduce it, and I can't post a SSCCE form the original program, it involves too much units and forms. The problem is not with the component but in the code. — Gab, Oct 25 '13 at 20:28
I can't reproduce in another program, with only a form, a bar and a button. I can reproduce it in the program but making an SSCCE out of this is not an option. I just edited the code ta make it clearer. — Gab, Oct 25 '13 at 20:35
I'll take a wild guess that you have some sort of thread, timer, or something, which is doing some sort of GUI updates other than just this progress bar. Something which tends to lock your GUI for brief moments, quite possibly even a deadlock. — Jerry Dodge, Oct 26 '13 at 14:54

Gab · Accepted Answer · 2013-10-25T22:17:47.317

0

Found it!

For the known workaround to work, the progress bar's state must be set to pbsNormal(it is by default). After that, instead of using

ProgressBar1.StepIt;

Use

pbMain.StepBy(1);
pbMain.StepBy(-1);
pbMain.StepBy(1);

edited Oct 25 '13 at 22:17

answered Oct 25 '13 at 21:57

Gab

681
4
14
27

How does this answer the question? Don't you also need to edit the question to explain the problem? Interestingly I already told you to do exactly what you have written here but you said "they don't work". Perhaps it might be best to just delete the entire question. How is a future visitor going to learn. On the other hand, if you could make the problem clear in the question, with an SSCCE then there could be value. – David Heffernan Oct 26 '13 at 05:18
From that so-called "solution" I would guess that you really go a bug somewhere in ypour code and this only cures the symptom somehow. At least today. Chances are, that you will be back tomorrow with the same problem. – JensG Oct 26 '13 at 17:58
1

@JensG this is a standard way to avoid the sometimes unwanted behaviour of Vista and later progress bars where their animation lags behind the actual position value. See the questions I linked to in comments to question. – David Heffernan Oct 27 '13 at 11:30
I see. Is that so-called "feature" documented somewhere? Never read about it, but now that you are saying it, I think I have experienced it too, but never ever thought of it being a Windows "feature". – JensG Oct 27 '13 at 12:03
@DavidHeffernan The problem is that the "fix" that you stated works only if the bar is set to pbsNormal. As STATED in the question, mine was set to pbsPaused. – Gab Nov 03 '13 at 20:45
1

@JensG No I won't. The fix found everywhere here work perfectly. My only problem was that they work if the bar's state is set to pbsNormal and mine was set to pbsPaused for aesthetic reasons. – Gab Nov 03 '13 at 20:46

Progress bar stops at 3/4 even if Position=4 and Max=4. Delphi

1 Answers1