Creating reports and dashboards | Stimulsoft community forum

Hello,

"Entire report processing" means as follows:
1. Load report from file/stream.
2. Create data dictionary, synchronize and connect
3. Register data source(s)
4. Compile
5. Render
6. Show or print

In Stimulsoft engine we have build-in progress bar for only render process (5) and unfortunately it's indeterminate - does not show progress of work (in percents or something).

Q1: How to determine total amount of work to do while rendering?
Q2: Is it possible to make custom progress bar for other processing steps?

--
Mariusz

Hello Mariusz,

Q1: How to determine total amount of work to do while rendering?

Report engine don't know how many pages will be rendered in report.

Q2: Is it possible to make custom progress bar for other processing steps?

At this moment no.

Thank you.

Q1: How to determine total amount of work to do while rendering?

Report engine don't know how many pages will be rendered in report.

Well, it sure doesn't. But, obviously, it can estimate the total amount of work to do and show (or allow to get for custom progress bar) current progress of work. Less precisely than current page or percent, but much more precisely than now.

Q2: Is it possible to make custom progress bar for other processing steps?

At this moment no.

Both problems are important to those of us, who want to develop user-friendly UI. Now user is sticking with endless moving bars (or something similar) and the time of this state is quite long and annoying with big data.
Consider to implement better work progress handle, please.

--
Mariusz

Hello Mariusz,

[quote="m".n]

Well, it sure doesn't. But, obviously, it can estimate the total amount of work to do and show (or allow to get for custom progress bar) current progress of work. Less precisely than current page or percent, but much more precisely than now.

Some time ago we already try to do it, but really its is not possible. Which data we have to calculate amount of work? Amount of rows in table? Amount of components on page? Its will be work (approximately) only for very simple reports.

Thank you.

Some time ago we already try to do it, but really its is not possible. Which data we have to calculate amount of work? Amount of rows in table? Amount of components on page? Its will be work (approximately) only for very simple reports.

While compiling, the amount of components seems to be the best measure of work to do.

While rendering... the simplest idea is: count all Data Bands, for each of them count data rows, that is total number of steps to go. Now, when reading of current data row (for current Data Band) is done, one work step is over. This should work even for complex reports.

--
Mariusz

Many reports will have properties set on their components for Can Grow and Can Shrink. You will also have components set to not print on certain pages, or to break and start on a new page e.g. GroupHeaderBand.
These properties will dramatically affect the number of pages generated by a report. The only way to calculate the amount of space for each one of these is to measure the size of their text.

The only way to accurately determine the number of pages a report uses would probably have to result in a two pass render and personally I wouldn't like time it takes to do this for very large reports. Just my 2c as to why a page count cannot be determined on render.

Hello,

As I wrote before, it is clearly understood there is no way to count total amount of pages before rendering them all. But I also wrote, it is not necessary to do this. I suggested a simple idea how the thing can be made, too.

I wonder why the users of this nice printing tool say "we need not it" or "it can't be done, so leave it as is". I understand why authors do so, but why the users? What are your UIs doing while printing engine renders time-consuming report? Fancy animated GIFs, or something?

--
Mariusz

I have an indeterminate progress bar + a text area in a dialog.
In the text area I give descriptions for exactly the steps you indicated in your first post.
During rendering, I use the render event to update the text area for each page.
So it still isn't very accurate but at least the user knows what's going on.

Hartmut

I just use the default indeterminate progress bar and let it count the number of pages rendered.
Either way, the user will have to wait for the report to finish rendering anyway. As long as mine are getting feedback they are fine with it.

Maybe a little statistics, as an addition to our dispute.

First we run for 6 seconds:

5 seconds - it's for creating StiReport
1 second - for report.Compile()

And then:

40 pages printout:
3 seconds - report.Render()
3 seconds - report.ShowWithWpf()
Total: 12 seconds

2000 pages printout:
1 minute and 43 seconds - report.Render()
16 seconds - report.ShowWithWpf()
Total: 2 minutes and 5 seconds

So, complex (determinate) progress bar for most printouts (i.e. a few pages) is not necessary at all, indeterminate one with additional text messages, as drhkocher wrote, or even default, is good enough. Well, timings are pretty good even for 40 pages . Good work, Stimulsoft team.

But for larger reports (thousands of pages - for interactive preview rather than for printing, of course), every good programmer, who cares about fine, user-friendly UI, should implement better progress bar. I do care and I'll try to do so.