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
Custom progress bar during entire report processing
Custom progress bar during entire report processing
Hello Mariusz,
Thank you.
Report engine don't know how many pages will be rendered in report.Q1: How to determine total amount of work to do while rendering?
At this moment no.Q2: Is it possible to make custom progress bar for other processing steps?
Thank you.
Custom progress bar during entire report processing
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.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.
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.Q2: Is it possible to make custom progress bar for other processing steps?
At this moment no.
Consider to implement better work progress handle, please.
--
Mariusz
Custom progress bar during entire report processing
Hello Mariusz,
[quote="m".n]
Thank you.
[quote="m".n]
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.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.
Thank you.
Custom progress bar during entire report processing
While compiling, the amount of components seems to be the best measure of work to do.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 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
Custom progress bar during entire report processing
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.
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.
Custom progress bar during entire report processing
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
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
Custom progress bar during entire report processing
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
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
Custom progress bar during entire report processing
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.
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.
Custom progress bar during entire report processing
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.
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.