Progress Bar calculations 3

[Bryan - Gendev]

My apologies for such a 'dumb' question - my 73 y.o. brain cells aren't as agile as they used to be.

I have a progress bar in my new little app.

I wish to show a continuous output for the 'processing' part of the app.

The processing is in 2 parts

First part - a constant - leaves the progress bar at 35%

Second part is where I have the problem.

This is a scanning loop of a table of an unknown number of records.

So I will need to add a fraction to the bar after each record. If the bar starts at say point1 after the first part - what will the increment be after each record is processed in the loop?

Hoping someone can help - thanks!

GenDev

 

[NasibKalsi]

Depending on the cpu/harddisk speed the progress bar will show high or low speed or your screen updates. I think use the seconds() function and display every so many seconds or fractions of a seconds. Take special care not to display too often which could cause sluggish behavior. Test your overall execution time by display once every second versus 10 times every seconds.

nasib

 

[Olaf Doschke]

Well, first of all a progressbar should grow linear in time and since your 2nd part can take various percentages, I'd doubt the 1st process ends at exactly 35% of the time needed.
But if taking that decision as given, the 2nd process now has 35% as it's 0% and so every value just has to be shrinked to the 65% rest of the bar and 35% added on that.

There is no situation you don't know your record count and already start iterating, use RECCOUNT(), than you know the count.

Bye, Olaf.

 

[GriffMG]

Olaf, there are conditions where you don't know (initially) how many records are in the scope of what you are processing.

RECCOUNT() will give the total number of records in a table, but that probably only represents the MAXIMUM number of records.

If 99% of them are deleted (and thus perhaps out of scope) the progress bar would be meaningless.

The only way to be 100% sure of the figure is to preprocess the records (i.e. count the ones in scope) use that as your guide
and then continue your progress bar. Of course that is exactly what M$ Windows does now whenever you cut/copy/paste files and
it is really irritating because it is so slow at it.

This does rather miss the point though; that progress bars are really just there to show 'something is going on'.



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Mike Lewis]

In this scenario, I would consider having two progress bars. I don't mean two physically different controls. I mean have the progress bar show the first phase, reaching 100% when it has finished, then do the same for the second phase. In addition, display a label close to bar that says "Phase 1 of 2" or "Phase 2 of 2" (or some other text text that means something to the user).

As for how to vary the percentage for the second phase, you mention "an unknown number of records". But you always know how many records there are in a given cursor or table. And you also know how many you have processed so far. So those two figures will give you the percentage (assuming, of course, that the records to be processed are evenly reasonably distributed in the cursor).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Griff,

you are of course right. I forgot about FILTER or other condition. I'd rather query data into a cursor and thereby have either RECCOUNT() or _TALLY available.
There is no knowing or guessing how much % a single record are without knowing reccount, so you have to make it known anyway.

Otherwise I agree with Mike. As you can't really ensure the first part is taking exactly 35% of the time (this might be an estimate from experience) you rather show two progress bars. And why not use two progress bar controls for it? It's a well known pattern to have a two parts progress bar with the upper showing steps 1 to N and the secondary going from 0 to 100% for each step.

Anyway each record might need different time. One example I did for a customer is a progress during robocopy. In a first pass I let robocopy run in list only mode, just generating a log file of what it would do, which includes file names and their size. I sum this into a total of bytes (rather than a total of files). Then in a secondary pass I compute the bytes copied from the new log file written and can compute the percentage. This gives a more linear progress than robocopy can show itself, besides I'm not showing a DOS screen while running robocopy.

Any progress bar really worth this name has to have a measurement you can assume to work linear in time. And the speed of bytes copied is such a measurement, at least much better than number of files copied, if they are very different in size. This isn't always possible, eg if it was about downloading rather than copying the speed can vary very much with the bandwidth being a bottleneck both on the server side, your isp or even your LAN.

The essence of all this: If you have two or more phases rather show them instead of trying to cover the whole process with a single progress bar, as you can't really determine the progress percentage anyway.

Bye, Olaf.

 

[Bryan - Gendev]

Thanks to you all for giving me ideas as to how to proceed.

Gendev