The Perfect Progress Bar

Calico · 2010-05-26

Can anyone advise on how to create the "perfect" progress bar? By that I mean one that reaches 100% as the process it is indicating completes. In the formula -

Window.UPDATE(1,ROUND(Counter/RecordCount * SomeNumber,1));

what relationship should "SomeNumber" bear to "RecordCount"? A lot I see are just set at 10,000 but some are a calculation based on RecordCount such as POWER(10,STRLEN(FORMAT(RecordCount))). And should the rounding be up or down?

And in the Text Constant are there any guidelines for the length of "@1################## " based on the number of records?

A lot of progress bars show 100% well before the process has actually completed and whereas others only reach 10%. The former is annoying and the latter disconcerting for the user. I'd be interested, and grateful for any advice.

Luc_VanDyck · 2010-05-26

This How To can be useful: How To use a progressbar in Dynamics NAV?
As is this download: NAV Progressbar

Calico · 2010-05-26

Thanks for the reply but unfortunately the only thing "How To" tells you is not to update the dialog with each iteration - which I already know and (don't) do. The examples in both the "How To" and the download use a multiplier of 10,000 but without any explanation, although the code in the download itself rounds down. Why 10,000?

einsTeIn.NET · 2010-05-26

1% is devided into 100 parts which means when you've got 100 (%) * 100 (parts) = 10.000 steps until you reach the whole progress bar (100%).

ara3n · 2010-05-26

The issue is that most people setup progress bar based on number of records that it is looping and if you have looped through all the records, you have reached the end 100%.

What they fail to realize that these processes are manipulating data on a database and at the end the NAV client commits the transaction, and that takes time.

So in a lot of these processes you reach 100 percent but still have to wait till the process commits the data. This is now more true since we have bulk insert.

FDickschat · 2010-05-26

As a general rule always update the progress bar at the latest possible moment after all the processing has been done and not at the beginning.
Always round down so that you don't reach 100% too early. This will solve updating the progress bar even if you loop through 1.000.000 records or more.

If you have a fixed number of records to loop through such a progress bar is easy.

MaxCnt := Table.COUNT;
Cnt := 0;
Repeat
  cnt += 1;  
  ...
  Your processing here
  ...  
  Progressbar.update(round(cnt / maxcnt * 10000, 1, '<'));
Until Table.next = 0;

Done.

But what if you don't know how many records your loop will need to process before starting the loop? E.g. the Adjust Cost Item Entries does not know at the beginning so it is not possible to fill MaxCnt.
Or in a Repeat Until there is an exit condition so the progress bar goes to 22% and the next thing you know it is finsihed and never reached 100%. I personally think that in these cases there should be no progress bar but just an indication that NAV is still doing something (like an Integer counting up).

rdebath · 2010-05-27

ara3n wrote:

The issue is that most people setup progress bar based on number of records that it is looping and if you have looped through all the records, you have reached the end 100%.

What they fail to realize that these processes are manipulating data on a database and at the end the NAV client commits the transaction, and that takes time.

So in a lot of these processes you reach 100 percent but still have to wait till the process commits the data. This is now more true since we have bulk insert.

While the commit can take a while that's not the whole problem. Also the delayed insert is limited in that it only buffers a small amount when it has 'enough' records in the buffer it sends them to the SQL server.

The fact is that the dialog bar does go to 100% early. Try this ...

window.open('@1###################################');
window.update(1, 9912);
sleep(1000);
window.close;

It will show 100%, but simple rounding shouldn't get you 100% before 9950 and even that may be too soon for the users. So as the bar can only show percent anyway (the blue bar too) you may be better off doing a ROUND(abc,100,'<') rather than a ROUND(abc,1).

Even so I do tend to show the commit as a distinct dialog message.

The Perfect Progress Bar

Comments

Categories