Progress Bars

[sburden77]

Hello,
I've written a load all subfile program which takes about a minute to load and I'd like to display a progress bar with some text to the user. Has anyone added a progress bar to their program and if so please share how you did it.

Thanks

[dieter]

Hi,
for the most tasks we use a simple window, which shows a "non intelligent" progressbar. We use an animated gif that looks like a progressbar and is is turning around. You can find such gifs via Google. Try "progressbar animated gif" or someting else. Here you can see the window:

progressbar_window.PNG (11.87 KiB) Viewed 1715 times

The problem is that a window normally stays on the screen until the user clicks a button. We solved this problem by executing a pui.click() at the onload event of the screen format. Here you can the the attributes:

designer.PNG (38.57 KiB) Viewed 1715 times

In another programm we show the progress bei showing the number of records, which are already loaded. We refresh the screen every 3 seconds. The technique is the same. The RPG program sends a new mask with the updated record-counter in a loop every 3 seconds while loading the subfile. The mask does a pui.click() and returns the control to the RPG program.

Dieter

[sburden77]

Thanks Dieter for responding.

[Scott Klement]

I think Dieter's answer is perfect -- this is a good way to do progress bars.

Another way would be to make a screen similar to his that shows a moving bar wtih a "percent complete" on it. The problem with this, however, is that to update the bar, you need to make a network request. So to update from 1-100 percent, you'd need to send the screen 100 times, making 100 requests... IMHO, that's not very elegant.

But, if it's important to show a percent, let me know and I'll whip up an example.

[sburden77]

Scott, thanks for responding. Can you put something together for the percent. I'm going to try your suggestion too.

[Scott Klement]

Again -- I would recommend using Dieter's technique, NOT the one I'm going to post here... Dieter's technique is a much better way to do this.

But, if it's important to print a percent, you can do it using something like this... I'm attaching an example, in three source members:

• PROGRESSD.dspf.txt -- the DDS source for the display file
• PROGRESSR.rpgle.txt -- the RPG code for the PROGRESSR program.

The idea here is that your program will be looping as it loads the subfile. It should call PROGRESSR in that loop and pass the message to display and the current "percent loaded".

I've attached an example of how to call PROGRESSR as well:

• Test program to see how to call PROGRESSR

Try these out... I definitely prefer Dieter's method, though!

[sburden77]

Scott,

I followed your recommendation and used Dieter's approach and it works great. I'll code your method to test it out at a later time.

Thanks again to the both of you.

Best regards

[t.s.h]

Scott, we build-in your progress bar example in a couple of programs and think it's really cool.

But we have some issues I haven't found a solution for:

1. every time the progressbar program is called and the control is coming back to the calling one all database driven select boxes in the previous screen are refreshed without an explicit exfmt/read or write in the calling program.

2. if the previous screen / program has large datagrids/subfiles it seems to me that all grids are re-rendered.
The more data records are in the grid, the slower the process becomes.

This both facts slows down the process noticeable. Do you have an idea how to optimize this?

Thanks

[Scott Klement]

That progress bar code does do explicitly exfmt... did you look at the code? Since it does exfmt, it will always re-render everything, so the results you're seeing are expected.

Did you read the message, above, where I recommended that people NOT use this technique?

[t.s.h]

Hi Scott,

thanks for you answer and yes I read your message with your recommendation.
But at the moment it was the fastest way to provide our user with a functionality they already have in the green screen.
(we show progress and expected time for the rest of calculations)

Removing a functionality by moving to a modern platform with the argument "this does not work here"
generates automatically unpleasant questions as you surely can imagine. :(

No offense, we will find another way to solve this problem.